Implement SIP 64 as non-experimental

[odersky]

For the new syntax of givens and context bounds, see the diffs in reference/syntax.md.

[odersky]

Best reviewed commit by commit. Most changes are to docs or tests, there are only a few changes to the code.

[odersky]

Who would like to gve this a review? It's all pretty straightforward. Biggest real changes are in the docs.

[smarter]

Playing a bit with the implementation, I noticed some details that I believe weren't clear from the spec:

Context bounds for type members

I love this feature but I wonder if it could be used to bring extension methods in scope too:

trait Serializable[T]:
  extension (x: T) def serialize: String

trait Base:
  type Elem: Serializable

def test0(b: Base) =
  summon[Serializable[b.Elem]] // ok
  b.serialize // error

Naming context bounds

I expected the as bounds on classes and traits to create public given members:

case class CC1[X: Serializable as s](x: X):
  type Elem = X

def test1(c: CC1[?]) =
  c.s // error
  summon[Serializable[c.Elem]] // error

Adding a public alias isn't enough to have it summon-able like in the context bounds for type members example above:

case class CC2[X: Serializable as s](x: X):
  type Elem = X
  given s1: Serializable[Elem] = s

def test2(c: CC2[?]) =
  c.s1 // ok
  summon[Serializable[c.Elem]] // error

Even if we directly extend from a trait defining a context bound for a type member, I guess because of dealiasing:

case class CC3[X: Serializable](x: X) extends Base:
  type Elem = X

def test3(c: CC3[?]) =
  summon[Serializable[c.Elem]] // error
  val b: Base = c
  summon[Serializable[b.Elem]] // ok

---

Ultimately, I wish member selection worked as well for regular type bounds than context bounds:

trait Serialize { def serialize: String }
case class Foo[T <: Serializer](x: T)
Foo(...).x.serialize
// vs
case class Foo[T: Serializable](x: T) // maybe with `as s` so I still have the ability to not retain a reference to the typeclass instance
Foo(...).x.serialize

I don't see a clear path to get there so this is more food for thought than a PR review.

[odersky]

@smarter I think these additions would be good to have as feature requests.

[kyouko-taiga]

nit: consistent alignment

Suggested change

	OldGivenSig ::= [id] [DefTypeParamClause] {UsingParamClause} ‘:’ -- one of `id`, `DefTypeParamClause`, `UsingParamClause` must be present
	OldGivenSig ::= [id] [DefTypeParamClause] {UsingParamClause} ‘:’ -- one of `id`, `DefTypeParamClause`, `UsingParamClause` must be present

[kyouko-taiga]

I think the expansion should be shown.

[kyouko-taiga]

LGTM overall. I left a few inline comments for things that I think could be improved before it gets merged, but nothing looks like a blocker to me.

Very nice step forward!

[kyouko-taiga]

Suggested change

	OldGivenDef ::= [OldGivenSig] (AnnotType [‘=’ Expr] | StructuralInstance) -- syntax up to Scala 3.5, to be deprecated in the future
	OldGivenSig ::= [id] [DefTypeParamClause] {UsingParamClause} ‘:’ -- one of `id`, `DefTypeParamClause`, `UsingParamClause` must be present
	OldGivenDef ::= [OldGivenSig] (AnnotType ['=' Expr] | StructuralInstance) -- syntax up to Scala 3.5, to be deprecated in the future
	OldGivenSig ::= [id] [DefTypeParamClause] {UsingParamClause} ':' -- one of `id`, `DefTypeParamClause`, `UsingParamClause` must be present

[WojciechMazur]

I think this example is either not correct - it does not compile in neither plain Scala 3.6-nightly or with experimental:modularity.
It fails to parse by the compiler

[odersky]

yes that one is still in the works: #21643

[WojciechMazur]

This example might be incorrect aswell. I'm not sure it it's a bug or expected behaviour, but it fails to compile with

[error] No given instance of type Ord[Sorted.this.Element] was found for inferring the implementation of the deferred given instance given_Ord_Element in class Sorted

It does however compile when replacing class Collection with trait Collection

[odersky]

Oh yes, that's a bug. It should be trait.