Decide on final syntax for `given` parameters

[odersky]

It seems we have implicit consensus on given as the new name for implicit instances. It has a lot more support than its alternative delegate. So, let's take that as a given 😉

given is a good name for instances, but it does have a potential problem that given parameters and given instances are too easily confused. The example that made this painfully clear for me was in #7056, where we find:

given [T1 <: NonEmptyTuple, TZ <: Tuple] as Aux[T1, Head[T1] *: TZ]
given Aux[Tail[T1], TZ] = new Idnt[T1] {
  type Res = Head[T1] *: TZ
  def (t1: T1) idnt: Res = t1.head *: t1.tail.idnt
}

At first, I could make neither heads nor tails of it and thought that the parser was faulty. Then I realized that the second given is a parameter to the first! Sure, it should have been indented but still... The syntax is dangerously misleading.

One way to fix this is to choose different names for introducing parameters and instances. I.e., go back to delegate. Another way to fix it is to put given under parentheses, thereby using the standard way of expressing parameter dependencies. I.e. it would be

def f(x: T)(given Context): T
f(x)(given ctx)

instead of

def f(x: T) given Context: T
f(x) given ctx

This idea, originally proposed by @smarter, is elaborated in #7150 (docs only, no implementation).
One advantage is that it generalizes readily to implicit function types and literals. These would be

(given A) => B
(given x: A) => b

Another advantage is that it makes it possible to have normal parameters after given parameters, something we stopped allowing because the original syntax was so confusing.

A possible downside is in the application of multiple given arguments in one argument list. That would look like

f(given a, b)

instead of

f given (a, b)

The first syntax takes some getting used to, I think.

Another possible option is to keep given for instance definitions, but use something else for implicit parameters. where was suggested by @milessabin. But any solution has to work in all of the following cases:

• implicit parameters in methods
• implicit arguments
• implicit function literals
• implicit function types

where works OK for the first two, but not for the last two.

[odersky]

I realize that going back to given under parentheses looks more like the old implicit parameters. Are we turning in circles here, just replacing implicit by given? I think not. There are a lot of differences between given and implicit:

• given is a construct by itself, not a modifier for other definitions, so its syntax focuses on intent over mechanism,
• different approach to implicit conversions,
• given arguments are different from normal ones,
• many differences in details of implicit resolution.

Furthermore, given has the right connotation for both instance definitions and parameters, whereas implicit only works well for implicit parameters, is barely adequate for implicit definitions
(when I write implicit object o { ... } it's just as explicit as a normal one!), and would be completely wrong for explicitly given implicit arguments. So given is altogether a much better choice than implicit.

[smarter]

Another problem with the current syntax is that:

def foo given (x: A, y: B) = ...
def foo given (A, B) = ...

Mean different things, the first takes two implicits of type A and B, the second takes one implicit of type (A, B), so it's easy to make the mistake when changing code: https://twitter.com/travisbrown/status/1152530738144845830

[smarter]

Contrast with the parens-around-given approach:

def foo(given x: A, y: B) = ...
def foo(given A, B) = ...

Both of these mean the same thing, one has to write def foo(given (A, B)) to get an implicit of a tuple type.

[smarter]

Another possible option is to keep given for instance definitions, but use something else for implicit parameters. where was suggested by @milessabin. But any solution has to work in all of the following cases: [...]

At the risk of restarting the infinite syntax wars: I think inject could work for all of those

[liufengyun]

Another merit of putting given in parenthesis: it's much easier to see what's the return type of a method.

Compare

  def dyni given QuoteContext: PV[Int] => Expr[Int] = dyn[Int]

with

  def dyni(given QuoteContext): PV[Int] => Expr[Int] = dyn[Int]

For myself, the return type of the second is immediately obvious, but my brain spins a while until I figure out the return type of the first.

[smarter]

While we're on the subject of given instances, I think it's worth reconsidering the use of as, while given as Foo looks fine by itself, I think that it doesn't fit well with the rest of the language:

• In a method parameter list, given Foo means "an anonymous given of type Foo, and given x: Foo, but in a given instance definition, the equivalents are respectively given as Foo and given x as Foo, this is not symmetrical
• The syntax of given instances is rich enough that forgetting the as will yield something that parses but which means something completely different, yielding at best confusing error messages as in https://contributors.scala-lang.org/t/proposal-to-add-implied-instances-to-the-language/3070/195?u=smarter
• There's already a token for separating a term from its type, it's :

My proposal:

• Instead of:

  given IntOrd as Ord[Int] { ... }

  Use a column:

  given IntOrd: Ord[Int] { ... }

• Instead of:

  given as Ord[Int] { ... }

  Use nothing, like in a method parameter list, or an implicit function type:

  given Ord[Int] { ... }

• Instead of:

  given ListOrd[T] as Ord[List[T]] given (ord: Ord[T]) { ... }

  Use a column, and put the given clause before the type (like in classes, defs, etc):

    given OrdList[T](given Ord[T]): Ord[List[T]] { ... }

• Instead of:

  given [T] as Ord[List[T]] given (ord: Ord[T]) { ... }

  Write:

    given [T](given Ord[T]): Ord[List[T]] { ... }

  (or alternatively forbid anonymous parameterized givens, because when implicit resolution fails, they're going to make for hard-to-decypher compiler error messages)

[soronpo]

Please consider changing given to extension (as a soft keyword) for extension methods.

extension ListOps[T](xs: List[T]) {
  def second: T = xs.tail.head
  def third: T = xs.tail.tail.head
}

[liufengyun]

Regarding the syntax for import, currently it looks unnatural and a little verbose:

import A.{ given as TC }

For brainstorming, what about:

import A.{ the[TC] }

The downside of the proposal is that the is not a keyword.

[lavrov]

Giving the type of implicit instance after as is a bit confusing for me because it seems that as should introduce identifier instead as it does in SQL. 👍 to @smarter idea.

[LPTK]

it seems that as should introduce identifier instead as it does in SQL

Also in OCaml, where it's used like Scala's @ in patterns!

[ryanstull]

Yeah I like the idea of replacing as with : as that's how the type of a term is already denoted. I think @smarter's proposal feels more consistent with the rest of the language

[odersky]

The idea to regularize the language by choosing : over as is attractive. But it also causes a problem: In

given ListOrd[T](given X: T): Ord[List[T]] { 
   ...
}

it is very hard to see whether what we define is an anonymous given for a class ListOrd or a named
given for a class Ord. In fact, we have to scan ahead a long way until we find the : which clarifies what it is. Long scanning ahead is a problem for humans and for the parser.

The situation is not comparable with given parameters where we have to distinguish (given C) and (given x: C) since the only possible item in front of a colon is a simple identifier. That is easy to parse for both humans and compilers.

[smarter]

it is very hard to see whether what we define is an anonymous given for a class ListOrd In fact, we have to scan ahead a long way until we find the : which clarifies what it is.

I don't think we need to scan that far, as soon as we see the the paren introducing (given ..., we know that this isn't a type so it's not anonymous, furthermore editors are likely to syntax highlight : specially, and just seeing : on the line should be enough to realize it's not anonymous.

This could also be reinforced by encouraging named givens to always start with a lower-case letter:

given listOrd[T](given X: T): Ord[List[T]] { 
   ...
}

After all, the given generates both a class and a def, and the important part is that calling listOrd(foo) will return something of type Ord[List[T]], not that this is implemented using a class.

[odersky]

I don't think we need to scan that far, as soon as we see the the paren introducing (given ..., we know that this isn't a type so it's not anonymous

No, in fact the implemented type can be passed a given argument since what's on the right of the : is a class constructor, not a type. So (given ...) is still ambiguous.

This could also be reinforced by encouraging named givens to always start with a lower-case letter

That's a good convention. So that solves the human readability problem. The necessary lookahead in the parser is a solvable problem. That convinces me to go with : instead of as.

Follow-on question: Should we also use : for extends, like C#? That would make the language even more regular.