If that’s the only reason then I’d much rather a breaking change with a rewrite rule (since we will have such things anyway).
Dotty is supposed to have fewer ways to do things, this is a gigantic exception to that, and I’m really not seeing the justification.
I am not sure that works. Is
given intOrd: Ord[Int] ...
meant to say Ord[Int] is a given? Something is a given when it’s a fact, widely known or understood.
All object definitions are given in that sense. Often there are different ways to order structures, and it’s not a given to order them that way or not, but one can make one of them a default.
On the other hand when we have a use in an argument position given works very well, especially I think in the previous notation without parenthesis
def (t: T) sort[T] given Ord[T]
which states that the definition sort works only if given an extra argument (from the default environment).
What seems to be needed is a way to say “make this object a potential default” in 4 or 5 letters.
Btw other suggestions were made on issue 7151 were assume/assumed, provide/provided .
(give/given does have the very big advantage of being short.)
I like “assume” and it would make a lot of sense to import implicits with
assume order.intOrd
What is a bit odd is the declaration that something is assumable, makeable implicit, since in a way anything can be made implicit…
Could one redyce the use of implicits to an import statement such as assume? Then at least the implicits would be clearly visible. It seems that definining objects as potentially implicit is the weird thing.
What about an “import scala.lang.version 2”?
Could that allow “implicit/implicitly” to be used for Scala 3?
Personally, I think that I would prefer a few keywords with well defined meanings that than one keyword that can be used in lots of ways.
E.g. defining an extension method using an extension keyword would likely make code easier to read. Similarly defining a typeclass using a “typeclass” keyword would generally seem to be easier (at least for me) to understand.
Otherwise my fear is that “given” is just turning into different version of “implicit” and perhaps they are both closer to “magic”.
Slightly off topic, but I wonder whether extension method definitions might be a bit more readable with a dot in the definition to make the binding more obvious?
E.g.
extension {
def (xs: List[T]).second[T] = xs.tail.head
}
rather than:
given {
def (xs: List[T]) second[T] = xs.tail.head
}
Just a few thoughts,
Rob
If that’s the only reason then I’d much rather a breaking change with a rewrite rule (since we will have such things anyway).
That would not work. The problem is that a call f(x) means something different if f has an implicit parameter or a given parameter. Example:
val ctx: Context
def f1(implicit c: Context): Map[String, Int]
f1(ctx) // OK
f1("abc") // Type Error
versus:
def f2(given c: Context): Map[String, Int]
f2(ctx) // Type Error
f2(given ctx) // OK
f2("abc") // OK
So this means you cannot independently rewrite f without also rewriting all its callers. But such a “rewrite the whole world all at once” approach is simply impractical.
Martin - I meant a rewrite rule for call sites only, to insert the implicit keyword in function application that would previously correspond to an implicit parameter, to make that expect. Is that unfeasible?
That’s feasible, but only if the new and old definition syntax is different. How otherwise would we know whether to rewrite the caller?
Yes, sorry, I made a mistake. Just ignore the part that was specifically replying to you.
No one has mentioned that English “gift” is both a verb and a noun. It means both to give and the thing that is given, the present. Everyone likes presents!
It also means a talent, as when one is gifted, so that a special capability has been conferred by an unseen power.
In the current idiom, one could even speak of implicit chaining as re-gifting. And if an implicit requires adaptation, that would be gift wrapping.
And for those who take a dim view of implicits and their black artistry, “Gift” in German means poison. So anyone preferring a visual marker for what they might prefer not to take, need only capitalise to capitalise and profit.
So I propose “gift/Gift” as the succinct and multivalent keyword that satisfies all the use cases yet satisfies none.
Please ignore the part that was specifically replying to you.
Here, have a Monoid … 
gift is a great choice … it even has its own unicode character: 
Clearly the only way to resolve the current Scala syntax conundrum is to replace all Scala keywords by emojis:
🎁ListOrd[T](🎁Ord[T]): Ord[List[T]] =
🆕Ord[List[T]] 👉 Ⓜ️compare(x: List[T], y: List[T]) = ... 👈
