Trial: Use with instead of given for context parameters
#7973
Conversation
|
Changes in a nutshell:
One area where I feel given [Left, Right](given lubLeft: Lub[Right], lubRight: Lub[Right])(given lub2: Lub2[lubLeft.Output, lubRight.Output]): Lub[Left | Right] ...I believe this can be much more legible if we change to given [Left, Right]
with (lubLeft: Lub[Right], lubRight: Lub[Right])
with (lub2: Lub2[lubLeft.Output, lubRight.Output])
as Lub[Left | Right] ...
Another downside is that normal parameters following def f(x: T) with (y: U) (z: V) = ...We might simply disallow it, except that this definition could be the result of expanding a collective extension method: extension of (x: T) with (y: U) {
def f(z: V) = ....
}Still, these are in my opinion minor issues. The main advantage of the scheme is that it works well where it matters most: Defining context parameters. Everything else is second or third priority. |
|
I like that we get less of |
|
I quite like it. Pulling the |
|
Note that this looks a bit like C# constraints, only with |
Has |
|
In the group meeting yesterday there were concerns about def max(x: T, y: T) with Ord[T] : T = ...one is tempted to read // infix with
def max(x: T, y: T) with Ord[T] : T =
if x < y then y else x
def max(x: T, y: T)
with Ordering[T],
Numeric[T])
: T =
if x < y then y else x
// tag in front of (...). instead of `where`, one can also use `implicit` or `given`,
// the layout appearance is similar in each case.
def max(x: T, y: T)(where Ord[T]): T =
if x < y then y else x
def max(x: T, y: T)(
where
ord: Ordering[T],
n: Numeric[T]
): T =
if x < y then y else x
// Context parameters in `{...}`
def max(x: T, y: T){ Ord[T] }: T =
if x < y then y else x
def max(x: T, y: T) {
ord: Ordering[T],
n: Numeric[T]
}: T =
if x < y then y else x
// Have implicit parameters and normal parameters in one list, separated by `where` (or whatever).
def max(x: T, y: T where Ord[T]): T =
if x < y then y else x
def max(x: T, y: T
where
ord: Ordering[T],
n: Numeric[T]
): T =
if x < y then y else xComparing all of these, I believe is parsed |
|
Previously def dyni given QuoteContext : PV[Int] => Expr[Int] = dyn[Int]One parsing obstacle in the above is that def dyni with QuoteContext : PV[Int] => Expr[Int] = dyn[Int] |
|
Or, we may use def dyni with QuoteContext return PV[Int] => Expr[Int] = dyn[Int]
def max(x: T, y: T) with Ord[T] return T = ... |
|
What if def max(x: T, y: T) with Ord[T] as T = ...def dyni with QuoteContext as PV[Int] => Expr[Int] = dyn[Int]def foo(i: Int)
with Bar
with Zip
as String = ...It would have to be allowed in simple constructs as well: val x as Int = 1def f(i as Int) as Int = i * 2But would preferrably only be used where (I don't think the particular word |
|
I think in the end using |
Cool |
For given instances:
given ...
For context parameters
... with ...
For context functions
A ?=> B
Change doc pages accordingly
|
Superseded by #8017 |
This is the third experiment to change the current syntax that uses
givenfor both instances and parameters. Instead of fiddling with the instance keyword (witnessordefault) we change the parameter syntax by going back towith, which we had beforegiven.Using
givenfor parameters has several potential problems:givenwith too many similarities to the current status whereimplicitis used for everything.To start with browsing:
https://github.com/dotty-staging/dotty/blob/try-with/docs/docs/reference/contextual/motivation.md