Add Scala 3.6.2 announcement #1699

WojciechMazur · 2024-10-14T16:22:23Z

No description provided.

WojciechMazur · 2024-10-14T16:25:03Z

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

+
+Besides multiple bugfixes, this release stabilises multiple experimental features introduced to Scala language after careful review and acceptance by the [Scala Improvement Proposal's Commitee](https://docs.scala-lang.org/sips/). Many of these changes can have a significant impact on the Scala syntax and are introducing new amazing possibilities in writing concise, typesafe as well as easier, and easier to maintain code.
+
+## SIP-47 - Clause Interleaving


@sjrd Can I ask you for a technical review or some improvements, as you're one of the SIP authors

WojciechMazur · 2024-10-14T16:25:44Z

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

+}
+```
+
+## SIP-58 - Named Tuples


@odersky Can I ask you for a technical review or some improvements, as you're the author of these changes?

WojciechMazur · 2024-10-14T16:26:08Z

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

+    case User(name = `name`, id = userId) => userId
+```
+
+## SIP-62 - For-Comprehension Improvements


@KacperFKorban Can I ask you for a technical review or some improvements, as you're author of these changes?

Looks good, one small change I would make is to change the last sentence to:

It also introduces changes to how your code is desugared by the compiler, leading to a more optimized code by removing some redundant calls.

WojciechMazur · 2024-10-14T16:26:33Z

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

+
+It also introduces changes to how your code is desugared by the compiler to `map` method calls, leading to a more optimized code by removing redundant calls where possible.
+
+## SIP-64 - Improve Syntax for Context Bounds and Givens


@odersky Can I ask you for a technical review or some improvements, as you're the main author of these changes?

WojciechMazur · 2024-10-14T16:27:21Z

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

+
+_**Note**: It is important not to confuse changes under SIP-64 with the [experimental modularity improvements](https://dotty.epfl.ch/docs/reference/experimental/typeclasses.html) available under `-language:experimental.modularity` and `-source:future`. These changes are still being developed in the experimental phase and would require SIP committee acceptance before stabilisation.
+
+## SIP-56 Amendment: Match types extractors follow aliases and singletons


@sjrd Can I ask you for a technical review or some improvements, as you're the one responsible for match type specification? Probably the improvement can be better explained

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

bishabosha · 2024-10-14T20:23:15Z

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

+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:
+
+```scala
+for {


This still needs an experiemental import, was it meant to be stabilised?

Suggested change

for {

import scala.language.experimental.betterFors

for {

Right, yes. Nice catch!

Thank you for this catch. For some reason I though it was stable already. I'll mark it as experimental similarly to runtimeChecked

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

…s, make named tuples example less controversial

prolativ · 2024-10-16T14:12:40Z

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

+    case User(name = `name`, id = userId) => userId
+```
+
+Last, but not least, named tuples are opening a new paradigm of metaprogramming by letting you to compute structural types without need for macros!


Suggested change

Last, but not least, named tuples are opening a new paradigm of metaprogramming by letting you to compute structural types without need for macros!

Last, but not least, named tuples are opening a new paradigm of metaprogramming by letting you compute structural types without need for macros!

prolativ · 2024-10-16T14:18:56Z

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

+## SIP-62 - For-Comprehension Improvements
+
+Starting with Scala 3.6.0 you can take advantage of improvements to the for-comprehesnions syntax.
+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:


Suggested change

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:

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:

prolativ · 2024-10-16T14:21:59Z

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

+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.
+The goal of these changes is to simplify and narrow the syntax rules required to create a given instance. To name a few:
+
+- you can now replace the `with` keyword with `:` when defining the simple type classes,


Suggested change

- you can now replace the `with` keyword with `:` when defining the simple type classes,

- you can now replace the `with` keyword with `:` when defining simple type classes,

prolativ · 2024-10-16T14:25:31Z

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

+given Order[Int]:
+  def compare(x: Int, y: Int): Int = ???
+
+// Named given using named context bound parameter


Suggested change

// Named given using named context bound parameter

// Named given instance using named context bound parameter

prolativ · 2024-10-16T14:28:00Z

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

+
+- you can now replace the `with` keyword with `:` when defining the simple type classes,
+- context bounds can now be named and aggregated using `T : {A, B}` syntax,
+- given methods defining requring contextual arguments can now be defined and chained using value


Not quite clear what this sentence was supposed to mean

prolativ · 2024-10-16T14:33:04Z

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

+```
+
+Other changes to type classes involve the stabilisation of context bounds for type members.
+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.


Suggested change

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.

This mechanism allows defining an abstract given instance that needs to be provided by a class implementing the trait that defines an abstract given.

prolativ · 2024-10-16T14:36:49Z

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

+
+_**Note**: It is important not to confuse changes under SIP-64 with the [experimental modularity improvements](https://dotty.epfl.ch/docs/reference/experimental/typeclasses.html) available under `-language:experimental.modularity` and `-source:future`. These changes are still being developed in the experimental phase and would require SIP committee acceptance before stabilisation.
+
+## SIP-56 Amendment: Match types extractors follow aliases and singletons


A link to this SIP would be appreciated

prolativ · 2024-10-16T14:39:51Z

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

+
+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.
+This change should not affect the majority of users, however, it can lead to differences in how implicits are resolved.
+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.


Suggested change

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.

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.

prolativ · 2024-10-16T14:42:36Z

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

+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.
+
+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.
+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.


Suggested change

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.

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.

prolativ · 2024-10-16T14:43:17Z

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

+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.
+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.
+
+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.


Add the link to the blog post plz

sjrd · 2024-10-16T15:00:32Z

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

+
+# What’s new in 3.6.0?
+
+Besides multiple bugfixes, this release stabilises multiple experimental features introduced to Scala language after careful review and acceptance by the [Scala Improvement Proposal's Commitee](https://docs.scala-lang.org/sips/). Many of these changes can have a significant impact on the Scala syntax and are introducing new amazing possibilities in writing concise, typesafe as well as easier, and easier to maintain code.


Suggested change

Besides multiple bugfixes, this release stabilises multiple experimental features introduced to Scala language after careful review and acceptance by the [Scala Improvement Proposal's Commitee](https://docs.scala-lang.org/sips/). Many of these changes can have a significant impact on the Scala syntax and are introducing new amazing possibilities in writing concise, typesafe as well as easier, and easier to maintain code.

Besides multiple bugfixes, this release stabilises multiple experimental features introduced to Scala language after careful review and acceptance by the [Scala Improvement Proposal's Commitee](https://docs.scala-lang.org/sips/). Many of these changes can have a significant impact on the Scala syntax and are introducing new possibilities in writing concise, typesafe as well as easier, and easier to maintain code.

No need to over-hype language features 😁

sjrd · 2024-10-16T15:02:03Z

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

+
+The first major feature we're going to cover is the [clause interleaving](https://docs.scala-lang.org/sips/clause-interleaving.html).
+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.
+It would eliminate the need for intermediate representations introducing runtime overhead or usage of complicated polymorphic functions.


This last sentence is true, but without an example of what was needed before, is going to be confusing to any reader. Consider removing it.

sjrd · 2024-10-16T15:05:27Z

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

+  c <- doSth(a)
+  extension (values: Seq[T]) def toSorted: Seq[T] = ???


This indentation can't be right, here. I don't know what the snippet is supposed to contain.

sjrd · 2024-10-16T15:06:45Z

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

+
+_**Note**: It is important not to confuse changes under SIP-64 with the [experimental modularity improvements](https://dotty.epfl.ch/docs/reference/experimental/typeclasses.html) available under `-language:experimental.modularity` and `-source:future`. These changes are still being developed in the experimental phase and would require SIP committee acceptance before stabilisation.
+
+## SIP-56 Amendment: Match types extractors follow aliases and singletons


Add draft for 3.6.0 annoncment

524ba06

WojciechMazur commented Oct 14, 2024

View reviewed changes

bishabosha reviewed Oct 14, 2024

View reviewed changes

_posts/2024-11-19-release-notes-3.6.0.md Show resolved Hide resolved

bishabosha reviewed Oct 14, 2024

View reviewed changes

_posts/2024-11-19-release-notes-3.6.0.md Outdated Show resolved Hide resolved

bishabosha reviewed Oct 14, 2024

View reviewed changes

_posts/2024-11-19-release-notes-3.6.0.md Outdated Show resolved Hide resolved

bishabosha reviewed Oct 14, 2024

View reviewed changes

_posts/2024-11-19-release-notes-3.6.0.md Outdated Show resolved Hide resolved

bishabosha reviewed Oct 14, 2024

View reviewed changes

_posts/2024-11-19-release-notes-3.6.0.md Outdated Show resolved Hide resolved

Apply review comments: fix typos, add example for cumputed field name…

b4dd9a1

…s, make named tuples example less controversial

prolativ reviewed Oct 16, 2024

View reviewed changes

sjrd reviewed Oct 16, 2024

View reviewed changes

SethTisue changed the title ~~Add Scala 3.6.0 announcement~~ Add Scala 3.6.2 announcement Oct 28, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Scala 3.6.2 announcement #1699

Add Scala 3.6.2 announcement #1699

WojciechMazur commented Oct 14, 2024

WojciechMazur Oct 14, 2024

WojciechMazur Oct 14, 2024

WojciechMazur Oct 14, 2024

KacperFKorban Oct 14, 2024

WojciechMazur Oct 14, 2024

WojciechMazur Oct 14, 2024

sjrd Oct 16, 2024

bishabosha Oct 14, 2024

KacperFKorban Oct 15, 2024

WojciechMazur Oct 15, 2024

prolativ Oct 16, 2024

prolativ Oct 16, 2024

prolativ Oct 16, 2024

prolativ Oct 16, 2024

prolativ Oct 16, 2024

prolativ Oct 16, 2024

prolativ Oct 16, 2024

prolativ Oct 16, 2024

prolativ Oct 16, 2024

prolativ Oct 16, 2024

sjrd Oct 16, 2024

sjrd Oct 16, 2024

sjrd Oct 16, 2024

sjrd Oct 16, 2024


		Besides multiple bugfixes, this release stabilises multiple experimental features introduced to Scala language after careful review and acceptance by the [Scala Improvement Proposal's Commitee](https://docs.scala-lang.org/sips/). Many of these changes can have a significant impact on the Scala syntax and are introducing new amazing possibilities in writing concise, typesafe as well as easier, and easier to maintain code.

		## SIP-47 - Clause Interleaving


		It also introduces changes to how your code is desugared by the compiler to `map` method calls, leading to a more optimized code by removing redundant calls where possible.

		## SIP-64 - Improve Syntax for Context Bounds and Givens


		_Note: It is important not to confuse changes under SIP-64 with the [experimental modularity improvements](https://dotty.epfl.ch/docs/reference/experimental/typeclasses.html) available under `-language:experimental.modularity` and `-source:future`. These changes are still being developed in the experimental phase and would require SIP committee acceptance before stabilisation.

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

-for {
+import scala.language.experimental.betterFors
+for {

	Last, but not least, named tuples are opening a new paradigm of metaprogramming by letting you to compute structural types without need for macros!
	Last, but not least, named tuples are opening a new paradigm of metaprogramming by letting you compute structural types without need for macros!

	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:
	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:

	- you can now replace the `with` keyword with `:` when defining the simple type classes,
	- you can now replace the `with` keyword with `:` when defining simple type classes,

	// Named given using named context bound parameter
	// Named given instance using named context bound parameter

	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.
	This mechanism allows defining an abstract given instance that needs to be provided by a class implementing the trait that defines an abstract given.

	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.
	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.

	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.
	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.


		# What’s new in 3.6.0?

		Besides multiple bugfixes, this release stabilises multiple experimental features introduced to Scala language after careful review and acceptance by the [Scala Improvement Proposal's Commitee](https://docs.scala-lang.org/sips/). Many of these changes can have a significant impact on the Scala syntax and are introducing new amazing possibilities in writing concise, typesafe as well as easier, and easier to maintain code.

		c <- doSth(a)
		extension (values: Seq[T]) def toSorted: Seq[T] = ???

Add Scala 3.6.2 announcement #1699

Are you sure you want to change the base?

Add Scala 3.6.2 announcement #1699

Conversation

WojciechMazur commented Oct 14, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment