Skip to content

Commit 434e47e

Browse files
committed
Apply fixes/suggestions required after review
1 parent 2a43f6a commit 434e47e

File tree

1 file changed

+14
-16
lines changed

1 file changed

+14
-16
lines changed

_posts/2024-11-19-release-notes-3.6.0.md

Lines changed: 14 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,6 @@ Besides multiple bugfixes, this release stabilises multiple experimental feature
1616

1717
The first major feature we're going to cover is the [clause interleaving](https://docs.scala-lang.org/sips/clause-interleaving.html).
1818
With this change to the language, you're able to define multiple type parameter lists or place them after the first arguments list. Clause interleaving would benefit the path-dependent API creators.
19-
It would eliminate the need for intermediate representations introducing runtime overhead or usage of complicated polymorphic functions.
2019

2120
```scala
2221
trait Key { type Value }
@@ -57,7 +56,7 @@ extension (values: Seq[User])
5756
case User(name = `name`, id = userId) => userId
5857
```
5958

60-
Last, but not least, named tuples are opening a new paradigm of metaprogramming by letting you to compute structural types without need for macros!
59+
Last, but not least, named tuples are opening a new paradigm of metaprogramming by letting you compute structural types without need for macros!
6160
The `Selectable` trait now has a `Fields` type member that can be instantiated to a named tuple.
6261

6362
```scala
@@ -78,14 +77,14 @@ You can read more about named tuples in the [dedicated section of Scala 3 refere
7877
## SIP-62 - For-Comprehension Improvements
7978

8079
Starting with Scala 3.6.0 you can take advantage of improvements to the for-comprehesnions syntax.
81-
Major user-facing improvement introduced by [SIP-62](https://docs.scala-lang.org/sips/better-fors.html) is ability to start for-comprehension block with aliases:
80+
Major user-facing improvement introduced by [SIP-62](https://docs.scala-lang.org/sips/better-fors.html) is the ability to start a for-comprehension block with aliases:
8281

8382
```scala
84-
for {
85-
a = 1
86-
b <- Some(2)
87-
c <- doSth(a)
88-
extension (values: Seq[T]) def toSorted: Seq[T] = ???
83+
for
84+
a = 1
85+
b <- Some(2)
86+
c <- doSth(a)
87+
yield b + c
8988
```
9089

9190
It also introduces changes to how your code is desugared by the compiler, leading to a more optimized code by removing some redundant calls.
@@ -95,9 +94,8 @@ It also introduces changes to how your code is desugared by the compiler, leadin
9594
This release stabilises the [SIP-64](https://docs.scala-lang.org/sips/sips/typeclasses-syntax.html) introduced as experimental in Scala 3.5.0. These changes provide you with the new syntax for defining type class instances.
9695
The goal of these changes is to simplify and narrow the syntax rules required to create a given instance. To name a few:
9796

98-
- you can now replace the `with` keyword with `:` when defining the simple type classes,
97+
- you can now replace the `with` keyword with `:` when defining simple type classes,
9998
- context bounds can now be named and aggregated using `T : {A, B}` syntax,
100-
- given methods defining requring contextual arguments can now be defined and chained using value
10199
- conditional givens can also be defined with parameters
102100
- by-name givens can be defined using conditional given with empty parameters list
103101

@@ -110,7 +108,7 @@ trait Order[T]:
110108
given Order[Int]:
111109
def compare(x: Int, y: Int): Int = ???
112110

113-
// Named given using named context bound parameter
111+
// Named given instance using named context bound parameter
114112
given listOrdering: [T: Order as elementOrder] => Order[List[T]]:
115113
def compare(x: List[T], y: List[T]): Int = elementOrder.compare(x.head, y.head)
116114

@@ -133,7 +131,7 @@ given context: () => Context = ???
133131
```
134132

135133
Other changes to type classes involve the stabilisation of context bounds for type members.
136-
The next mechanism allows to definition of an abstract given instance that needs to be provided by the class implementing trait that defines abstract given.
134+
This mechanism allows defining an abstract given instance that needs to be provided by a class implementing the trait that defines an abstract given.
137135

138136
```scala
139137
trait Collection:
@@ -155,7 +153,7 @@ _**Note**: It is important not to confuse changes under SIP-64 with the [experim
155153

156154
## SIP-56 Amendment: Match types extractors follow aliases and singletons
157155

158-
Scala 3.6.0 also stabilises the improvements of match types previously available under `-language:experimental.betterMatchTypeExtractors`. These changes were amending the match type specification and adjusting the implementation of match types to resolve some of the issues reported by users. Under the new rules, it is possible to correctly resolve aliases and singleton types.
156+
Scala 3.6.0 also stabilises the improvements of match types previously available under `-language:experimental.betterMatchTypeExtractors`. These changes were amending the match type specification and adjusting the implementation of match types under [SIP-56](https://docs.scala-lang.org/sips/match-types-spec.html) to resolve some of the issues reported by users. Under the new rules, it is possible to correctly resolve aliases and singleton types.
159157

160158
```scala
161159
trait A:
@@ -192,7 +190,7 @@ val Some(appVersion) = config.get("appVersion").runtimeChecked
192190

193191
Until Scala 3.6.0 context bound parameters were always desugared to `implicit` arguments, starting with 3.6.0 these would be mapped to `using` parameters instead.
194192
This change should not affect the majority of users, however, it can lead to differences in how implicits are resolved.
195-
Resolution of implicits can slightly differ depending on whether we're requesting them using `implicit` or `using` parameter, or depending on whether it was defined using `implicit` or `given` keywords. The special behaviours were introduced to a smooth migration from Scala 2 to brand new implicits resolution in Scala 3.
193+
Resolution of implicits can slightly differ depending on whether we're requesting them using `implicit` or `using` parameter, or depending on whether they were defined using `implicit` or `given` keywords. The special behaviours were introduced to smoothen migration from Scala 2 to brand new implicits resolution in Scala 3.
196194
This change might also affect some of the projects that use compiler plugins or macros to inspect the implicit argument lists of the function calls - these might require some minor fixes, eg. when filtering symbols by their flags.
197195

198196
<!-- TODO: Create and link docs describing differences between given/implicit -->
@@ -202,9 +200,9 @@ This change might also affect some of the projects that use compiler plugins or
202200
In the [Scala 3.5.0 release notes](https://scala-lang.org/blog/2024/08/22/scala-3.5.0-released.html) we've announced upcoming changes to givens, due to their peculiar problem with prioritization. Currently, the compiler always tries to select the instance with the most specific subtype of the requested type. In the future, it would change to always selecting the instance with the most general subtype that satisfies the context-bound.
203201

204202
Starting from Scala 3.6.0, code whose behaviour can differ between new and old rules (ambiguity on new, passing on old, or vice versa) will emit warnings, but the old rules will still be applied.
205-
Running the compiler with `-source:3.5` will allow you to temporarily keep using the old rules; with `-source:3.7` or `-source:future` you will get to use the new scheme.
203+
Running the compiler with `-source:3.5` will allow you to temporarily keep using the old rules; with `-source:3.7` or `-source:future` the new scheme will be used.
206204

207-
For the detailed motivation of changes with examples of code that will be easier to write and understand, see our recent blog post - Upcoming Changes to Givens in Scala 3.7.
205+
For the detailed motivation of changes with examples of code that will be easier to write and understand, see our recent blog post - [Upcoming Changes to Givens in Scala 3.7]({{ site.baseurl }}/2024/08/19/given-priority-change-3.7.html).
208206

209207
## Require named arguments for Java-defined annotations
210208

0 commit comments

Comments
 (0)