Use : instead of as

Following the discussion in #7151, choose `:` instead of `as` for given clauses.

Author: odersky

docs/docs/reference/contextual/conversions.md

@@ -10,13 +10,13 @@ abstract class Conversion[-T, +U] extends (T => U)
 ```
 For example, here is an implicit conversion from `String` to `Token`:
 ```scala
-given as Conversion[String, Token] {
+given Conversion[String, Token] {
   def apply(str: String): Token = new KeyWord(str)
 }
 ```
 Using an alias this can be expressed more concisely as:
 ```scala
-given as Conversion[String, Token] = new KeyWord(_)
+given Conversion[String, Token] = new KeyWord(_)
 ```
 An implicit conversion is applied automatically by the compiler in three situations:
 
@@ -37,7 +37,7 @@ If such an instance `C` is given, the expression `e` is replaced by `C.apply(e)`
 primitive number types to subclasses of `java.lang.Number`. For instance, the
 conversion from `Int` to `java.lang.Integer` can be defined as follows:
 ```scala
-given int2Integer as Conversion[Int, java.lang.Integer] =
+given int2Integer: Conversion[Int, java.lang.Integer] =
  java.lang.Integer.valueOf(_)
 ```
 
@@ -59,9 +59,9 @@ object Completions {
     //
     //   CompletionArg.fromStatusCode(statusCode)
 
-    given fromString     as Conversion[String, CompletionArg]               = Error(_)
-    given fromFuture     as Conversion[Future[HttpResponse], CompletionArg] = Response(_)
-    given fromStatusCode as Conversion[Future[StatusCode], CompletionArg]   = Status(_)
+    given fromString     : Conversion[String, CompletionArg]               = Error(_)
+    given fromFuture     : Conversion[Future[HttpResponse], CompletionArg] = Response(_)
+    given fromStatusCode : Conversion[Future[StatusCode], CompletionArg]   = Status(_)
   }
   import CompletionArg._
 

docs/docs/reference/contextual/delegates.md

@@ -13,12 +13,12 @@ trait Ord[T] {
   def (x: T) > (y: T) = compare(x, y) > 0
 }
 
-given IntOrd as Ord[Int] {
+given intOrd: Ord[Int] {
   def compare(x: Int, y: Int) =
     if (x < y) -1 else if (x > y) +1 else 0
 }
 
-given ListOrd[T](given ord: Ord[T]) as Ord[List[T]] {
+given listOrd[T](given ord: Ord[T]): Ord[List[T]] {
 
   def compare(xs: List[T], ys: List[T]): Int = (xs, ys) match {
     case (Nil, Nil) => 0
@@ -30,19 +30,19 @@ given ListOrd[T](given ord: Ord[T]) as Ord[List[T]] {
   }
 }
 ```
-This code defines a trait `Ord` with two given instances. `IntOrd` defines
-a given for the type `Ord[Int]` whereas `ListOrd[T]` defines givens
+This code defines a trait `Ord` with two given instances. `intOrd` defines
+a given for the type `Ord[Int]` whereas `listOrd[T]` defines givens
 for `Ord[List[T]]` for all types `T` that come with a given instance for `Ord[T]` themselves.
-The `given (ord: Ord[T])` clause in `ListOrd` defines an implicit parameter.
+The `(given ord: Ord[T])` clause in `listOrd` defines an implicit parameter.
 Given clauses are further explained in the [next section](./given-clauses.md).
 
 ## Anonymous Given Instances
 
 The name of a given instance can be left out. So the definitions
 of the last section can also be expressed like this:
 ```scala
-given as Ord[Int] { ... }
-given [T](given Ord[T]) as Ord[List[T]] { ... }
+given Ord[Int] { ... }
+given [T](given Ord[T]): Ord[List[T]] { ... }
 ```
 If the name of a given is missing, the compiler will synthesize a name from
 the type(s) in the `as` clause.
@@ -51,7 +51,7 @@ the type(s) in the `as` clause.
 
 An alias can be used to define a given instance that is equal to some expression. E.g.:
 ```scala
-given global as ExecutionContext = new ForkJoinPool()
+given global: ExecutionContext = new ForkJoinPool()
 ```
 This creates a given `global` of type `ExecutionContext` that resolves to the right
 hand side `new ForkJoinPool()`.
@@ -60,8 +60,8 @@ returned for this and all subsequent accesses to `global`.
 
 Alias givens can be anonymous, e.g.
 ```scala
-given as Position = enclosingTree.position
-given (given outer: Context) as Context = outer.withOwner(currentOwner)
+given Position = enclosingTree.position
+given (given outer: Context): Context = outer.withOwner(currentOwner)
 ```
 An alias given can have type parameters and given clauses just like any other given instance, but it can only implement a single type.
 
@@ -78,11 +78,12 @@ Here is the new syntax of given instances, seen as a delta from the [standard co
 ```
 TmplDef          ::=  ...
                   |   ‘given’ GivenDef
-GivenDef         ::=  [id] [DefTypeParamClause] {GivenParamClause} GivenBody
-GivenBody        ::=  [‘as’ ConstrApp {‘,’ ConstrApp }] [TemplateBody]
-                   |  ‘as’ Type ‘=’ Expr
+GivenDef         ::=  GivenBody
+                  |   [id] [DefTypeParamClause] {GivenParamClause}
+                      (‘:’ GivenBody | ‘<:’ Type ‘=’ Expr)
+GivenBody        ::=  [ConstrApp {‘,’ ConstrApp }] [TemplateBody]
+                  |   Type ‘=’ Expr
 GivenParamClause ::=  ‘(’ ‘given’ (DefParams | GivenTypes) ‘)’
 GivenTypes       ::=  AnnotType {‘,’ AnnotType}
 ```
-The identifier `id` can be omitted only if either the `as` part or the template body is present.
-If the `as` part is missing, the template body must define at least one extension method.
+The identifier `id` can be omitted only if some types are implemented or the template body defines at least one extension method.

docs/docs/reference/contextual/derivation.md

@@ -19,9 +19,9 @@ The `derives` clause generates the following given instances for the `Eq`, `Orde
 companion object of `Tree`,
 
 ```scala
-given [T: Eq]       as Eq[Tree[T]]    = Eq.derived
-given [T: Ordering] as Ordering[Tree] = Ordering.derived
-given [T: Show]     as Show[Tree]     = Show.derived
+given [T: Eq]       : Eq[Tree[T]]    = Eq.derived
+given [T: Ordering] : Ordering[Tree] = Ordering.derived
+given [T: Show]     : Show[Tree]     = Show.derived
 ```
 
 We say that `Tree` is the _deriving type_ and that the `Eq`, `Ordering` and `Show` instances are _derived instances_.
@@ -175,7 +175,7 @@ we need to implement a method `Eq.derived` on the companion object of `Eq` that
 a `Mirror[T]`. Here is a possible implementation,
 
 ```scala
-inline given derived[T](given m: Mirror.Of[T]) as Eq[T] = {
+inline given derived[T](given m: Mirror.Of[T]): Eq[T] = {
   val elemInstances = summonAll[m.MirroredElemTypes]           // (1)
   inline m match {                                             // (2)
     case s: Mirror.SumOf[T]     => eqSum(s, elemInstances)
@@ -256,7 +256,7 @@ trait Eq[T] {
 }
 
 object Eq {
-  given as Eq[Int] {
+  given Eq[Int] {
     def eqv(x: Int, y: Int) = x == y
   }
 
@@ -281,7 +281,7 @@ object Eq {
         }
     }
 
-  inline given derived[T](given m: Mirror.Of[T]) as Eq[T] = {
+  inline given derived[T](given m: Mirror.Of[T]): Eq[T] = {
     val elemInstances = summonAll[m.MirroredElemTypes]
     inline m match {
       case s: Mirror.SumOf[T]     => eqSum(s, elemInstances)
@@ -312,7 +312,7 @@ In this case the code that is generated by the inline expansion for the derived
 following, after a little polishing,
 
 ```scala
-given derived$Eq[T](given eqT: Eq[T]) as Eq[Opt[T]] =
+given derived$Eq[T](given eqT: Eq[T]): Eq[Opt[T]] =
   eqSum(the[Mirror[Opt[T]]],
     List(
       eqProduct(the[Mirror[Sm[T]]], List(the[Eq[T]]))
@@ -329,13 +329,13 @@ As a third example, using a higher level library such as shapeless the type clas
 `derived` method as,
 
 ```scala
-given eqSum[A](given inst: => K0.CoproductInstances[Eq, A]) as Eq[A] {
+given eqSum[A](given inst: => K0.CoproductInstances[Eq, A]): Eq[A] {
   def eqv(x: A, y: A): Boolean = inst.fold2(x, y)(false)(
     [t] => (eqt: Eq[t], t0: t, t1: t) => eqt.eqv(t0, t1)
   )
 }
 
-given eqProduct[A](given inst: K0.ProductInstances[Eq, A]) as Eq[A] {
+given eqProduct[A](given inst: K0.ProductInstances[Eq, A]): Eq[A] {
   def eqv(x: A, y: A): Boolean = inst.foldLeft2(x, y)(true: Boolean)(
     [t] => (acc: Boolean, eqt: Eq[t], t0: t, t1: t) => Complete(!eqt.eqv(t0, t1))(false)(true)
   )
@@ -354,7 +354,7 @@ change the code of the ADT itself.  To do this, simply define an instance using
 as right-hand side. E.g, to implement `Ordering` for `Option` define,
 
 ```scala
-given [T: Ordering] as Ordering[Option[T]] = Ordering.derived
+given [T: Ordering] : Ordering[Option[T]] = Ordering.derived
 ```
 
 Assuming the `Ordering.derived` method has a given parameter of type `Mirror[T]` it will be satisfied by the

docs/docs/reference/contextual/extension-methods.md

@@ -50,7 +50,7 @@ trait StringSeqOps {
 ```
 We can make the extension method available by defining a given `StringSeqOps` instance, like this:
 ```scala
-given ops1 as StringSeqOps
+given ops1: StringSeqOps
 ```
 Then
 ```scala

docs/docs/reference/contextual/given-clauses.md

@@ -74,9 +74,9 @@ def f(u: Universe)(given c: u.Context)(given s: ctx.Symbol, k: ctx.Kind) = ...
 Multiple given clauses are matched left-to-right in applications. Example:
 ```scala
 object global extends Universe { type Context = ... }
-given ctx as global.Context { type Symbol = ...; type Kind = ... }
-given sym as ctx.Symbol
-given kind as ctx.Kind
+given ctx  : global.Context { type Symbol = ...; type Kind = ... }
+given sym  : ctx.Symbol
+given kind : ctx.Kind
 ```
 Then the following calls are all valid (and normalize to the last one)
 ```scala

docs/docs/reference/contextual/implicit-by-name-parameters.md

@@ -10,9 +10,9 @@ trait Codec[T] {
   def write(x: T): Unit
 }
 
-given intCodec as Codec[Int] = ???
+given intCodec: Codec[Int] = ???
 
-given optionCodec[T](given ev: => Codec[T]) as Codec[Option[T]] {
+given optionCodec[T](given ev: => Codec[T]): Codec[Option[T]] {
   def write(xo: Option[T]) = xo match {
     case Some(x) => ev.write(x)
     case None =>
@@ -36,7 +36,7 @@ The precise steps for synthesizing an argument for an implicit by-name parameter
  1. Create a new given instance of type `T`:
 
     ```scala
-    given lv as T = ???
+    given lv: T = ???
     ```
     where `lv` is an arbitrary fresh name.
 
@@ -46,7 +46,7 @@ The precise steps for synthesizing an argument for an implicit by-name parameter
 
 
     ```scala
-    { given lv as T = E; lv }
+    { given lv: T = E; lv }
     ```
 
     Otherwise, return `E` unchanged.

docs/docs/reference/contextual/implicit-function-types.md

@@ -12,7 +12,7 @@ type Executable[T] = (given ExecutionContext) => T
 An implicit function is applied to synthesized arguments, in
 the same way a method with a given clause is applied. For instance:
 ```scala
-  given ec as ExecutionContext = ...
+  given ec: ExecutionContext = ...
 
   def f(x: Int): Executable[Int] = ...
 
@@ -83,13 +83,13 @@ with implicit function types as parameters to avoid the plumbing boilerplate
 that would otherwise be necessary.
 ```scala
   def table(init: (given Table) => Unit) = {
-    given t as Table
+    given t: Table
     init
     t
   }
 
   def row(init: (given Row) => Unit)(given t: Table) = {
-    given r as Row
+    given r: Row
     init
     t.add(r)
   }

docs/docs/reference/contextual/import-delegate.md

@@ -3,12 +3,12 @@ layout: doc-page
 title: "Import Given"
 ---
 
-A special form of import selector is used to import given instances. Example:
+A special form of import wildcard selector is used to import given instances. Example:
 ```scala
 object A {
   class TC
-  given tc as TC
-  def f where TC = ???
+  given tc: TC
+  def f(given TC) = ???
 }
 object B {
   import A._
@@ -19,16 +19,16 @@ In the code above, the `import A._` clause of object `B` will import all members
 of `A` _except_ the given instance `tc`. Conversely, the second import `import A.given` will import _only_ that given instance.
 The two import clauses can also be merged into one:
 ```scala
-object B:
+object B
   import A.{given, _}
 ```
 
-Generally, a normal import selector brings definitions other than given instances into scope whereas a `given` import selector brings only given instances into scope.
+Generally, a normal wildcard selector `_` brings all definitions other than given instances into scope whereas a `given` selector brings all given instances into scope.
 
 There are two main benefits arising from these rules:
 
  - It is made clearer where givens in scope are coming from.
-   In particular, it is not possible to hide imported givens in a long list of regular imports.
+   In particular, it is not possible to hide imported givens in a long list of regular wildcard imports.
  - It enables importing all givens
    without importing anything else. This is particularly important since givens
    can be anonymous, so the usual recourse of using named imports is not
@@ -39,32 +39,32 @@ There are two main benefits arising from these rules:
 Since givens can be anonymous it is not always practical to import them by their name, and wildcard imports are typically used instead. By-type imports provide a more specific alternative to wildcard imports, which makes it clearer what is imported. Example:
 
 ```scala
-import A.{given as TC}
+import A.{given TC}
 ```
 This imports any given in `A` that has a type which conforms to `TC`. Importing givens of several types `T1,...,Tn`
 is expressed by multiple `given` selectors.
 ```
-import A.{given as T1, ..., given as Tn}
+import A.{given T1, ..., given Tn}
 ```
 Importing all given instances of a parameterized type is expressed by wildcard arguments.
 For instance, assuming the object
 ```scala
 object Instances {
-  given intOrd as Ordering[Int]
-  given [T: Ordering] listOrd as Ordering[List[T]]
-  given ec as ExecutionContext = ...
-  given im as Monoid[Int]
+  given intOrd: Ordering[Int]
+  given [T: Ordering] listOrd: Ordering[List[T]]
+  given ec: ExecutionContext = ...
+  given im: Monoid[Int]
 }
 ```
 the import
 ```scala
-import Instances.{given as Ordering[?], given as ExecutionContext}
+import Instances.{given Ordering[?], given ExecutionContext}
 ```
 would import the `intOrd`, `listOrd`, and `ec` instances but leave out the `im` instance, since it fits none of the specified bounds.
 
 By-type imports can be mixed with by-name imports. If both are present in an import clause, by-type imports come last. For instance, the import clause
 ```scala
-import Instances.{given im, given as Ordering[?]}
+import Instances.{im, given Ordering[?]}
 ```
 would import `im`, `intOrd`, and `listOrd` but leave out `ec`.
 
@@ -89,15 +89,13 @@ normal imports to given instances and imports.
 The following modifications avoid this hurdle to migration.
 
  1. A `given` import selector also brings old style implicits into scope. So, in Scala 3.0
-    an old-style implicit definition can be brought into scope either by a normal import or by an import given.
+    an old-style implicit definition can be brought into scope either by a `_` wildcard import or by a `given` import.
 
- 2. In Scala 3.1, old-style implicits accessed through a normal import
-    will give a deprecation warning.
+ 2. In Scala 3.1, old-style implicits accessed through a `_` wildcard import will give a deprecation warning.
 
- 3. In some version after 3.1, old-style implicits accessed through a normal import
-    will give a compiler error.
+ 3. In some version after 3.1, old-style implicits accessed through a `_` wildcard import will give a compiler error.
 
-These rules mean that library users can use `import given` to access old-style implicits in Scala 3.0,
+These rules mean that library users can use `given` imports to access old-style implicits in Scala 3.0,
 and will be gently nudged and then forced to do so in later versions. Libraries can then switch to
 representation clauses once their user base has migrated.
 
@@ -110,9 +108,9 @@ ImportSpec        ::=  id
                     | ‘_’
                     | ‘given’
                     | ‘{’ ImportSelectors) ‘}’
-ImportSelectors   ::=  [‘given’] id [‘=>’ id | ‘=>’ ‘_’] [‘,’ ImportSelectors]
+ImportSelectors   ::=  id [‘=>’ id | ‘=>’ ‘_’] [‘,’ ImportSelectors]
                     |  WildCardSelector {‘,’ WildCardSelector}
-WildCardSelector  ::=  ‘given’ [‘as’ InfixType]
+WildCardSelector  ::=  ‘given’ [InfixType]
                     |  ‘_' [‘:’ InfixType]
 Export            ::=  ‘export’ ImportExpr {‘,’ ImportExpr}
 ```