Add new givens example

blog/_posts/2024-08-21-scala-3.5.0-released.md

@@ -97,6 +97,39 @@ point match
 
 This is an implementation of [SIP-58](https://github.com/scala/improvement-proposals/blob/d649f6e6f333cd9232d85a12bd0445d18a673f10/content/named-tuples.md).
 
+### Experimental: new givens and context bounds syntax
+
+Another experimental feature introduced in Scala 3.5 is the new syntax for type classes. Some of these improvements are: `Self` type member instead of the type parameter, auxiliary type alias `is` or named context bounds, just to name a few.
+The full list of proposed improvements and their examples can be found under [Modularity Improvements](https://scala-lang.org/api/3.5.0/docs/docs/reference/experimental/modularity.html) and [Better Support for Type Classes](https://scala-lang.org/api/3.5.0/docs/docs/reference/experimental/typeclasses.html).
+To test the new syntax you would be required to use both the source version `future` and the additional language import `experimental.modularity`. 
+
+```scala
+//> using options -source:future -language:experimental.modularity
+
+trait Ord:
+ type Self
+ extension (x: Self)
+ def compareTo(y: Self): Int
+ def < (y: Self): Boolean = compareTo(y) < 0
+ def > (y: Self): Boolean = compareTo(y) > 0
+
+given intOrd: (Int is Ord) with
+ extension (x: Int) def compareTo(y: Int) = if x < y then -1 else if x > y then +1 else 0
+
+def descending[T: Ord as asc]: T is Ord = new:
+ extension (x: T) def compareTo(y: T) = asc.compareTo(y)(x)
+
+def maximum[T](xs: List[T])(using T is Ord): T =
+ xs.reduceLeft((x, y) => if (x < y) y else x)
+
+val xs = List(1, 2, 3)
+val _ = maximum(xs)
+val _ = maximum(xs)(using descending)
+val _ = maximum(xs)(using descending(using intOrd))
+```
+
+This is an implementation of [SIP-64](https://github.com/scala/improvement-proposals/blob/db5cc6ab92758272f1a3528eacb46182ea216323/content/typeclasses-syntax.md).
+
 ## Work on a better scheme for given prioritization
 
 Givens in Scala 3 have a peculiar problem with prioritization. The compiler tries to always select the instance with *the most specific subtype* of the requested type. This can lead to confusing situations, when user faces ambiguity errors in code that should intuitively work. Changing the scheme of given prioritization to always select the instance with *the most general subtype* that satisfies the context bound, would resolve such cases. We have conducted experiments that showed that the proposed scheme will result in a more intuitive and predictable given resolution. The negative impact on the existing projects is very small. We have tested 1500 open-source libraries, and new rules are causing problems for less than a dozen of them. We have already submitted PRs with changes that will make them work the same way under both the current and proposed rules.