Proposal To Revise Implicit Parameters

I like idea with given as function call f.given(a)(b).given(c) but it moves back to first implementation that was proposed few years ago f.implicitly(a)(b).implicitly(c). Why original proposition was abandoned?

This volatile also first rule:

Maybe we should also accept same syntax on definition site then?

def f(x: Double).given(ctx: Context):Double = { ... } 
1 Like

If I want to respond directly to a point made, how can I do that? Can I split off a separate thread by replying to a post here?

+1 to infer and inferred over implied

I don’t remember implicitly keyword being suggested, but anyway implicitly is already present in Scala’s stdlib as a function and it’s frequently used. You would first need to deprecate that method in Scala Next and only in Scala Next+1 you would have a chance to reintroduce implicitly as a keyword. To avoid that lengthy process you need to choose another keyword.

It’s not a keyword, it would be a method, much like apply

I don’t want to hijack this thread (and started a new one on Scala governance to take any further discussion there), but I feel this statement needs a reply:

I think you’re over-interpreting this. I mean, Martin does not
have the final say here, the SIP committee does. Yes, he’s extremely influential in the process, but we’ve long since moved on from “everything Martin says is final”.

I don’t think that is entirely correct. The SIP submission process details:

For a SIP to be accepted, the following three requirements must be met:

  • At least 50% of the committee members vote in favor.
  • There are at least two-thirds “in favor” versus “against” votes.
  • Martin Odersky does not veto it.

AFAIK, he can only veto against a proposal, but not in favor.

I agree with @lihaoyi, even if we use the given syntax, we should instead choose another keyword that is more familiar to mainstream language developers.

The alternative keywords to given that I can imagine include:

  • autowire
  • inject
  • import
1 Like

I propose changing

delegate for

to

delegate as

eg

s/delegate (.*) for/delegate $1 as/

Old Post:
I propose changing

implied for

to

implied as

eg

s/implied (.*) for/implied $1 as/

implied was recently changed to delegate see https://github.com/lampepfl/dotty/pull/6649
It’s already the syntax in dotty 0.16.0-RC3

Replacing “implied” with “delegate” seems a big step backwards for learnability. It will likely confuse and mislead those familiar with the design pattern having the same name. It will also confuse and mislead anyone with experience in C#, in which the “delegate” keyword means something different. I was quite happy with “implied,” and thought it added much needed clarity, but if the community insists on changing it, perhaps consider something else: “default” maybe? Conceptually a “default” instance of a type might be considered analogous to a default method parameter.

5 Likes

Oooh that is a very nice suggestion, and “default” is also a noun :heavy_check_mark: !

One problem I see: unfortunately, “default” is a longer form of “def” which creates confusion about their relationship.

1 Like

Watch Martin’s recent Scala Days keynote. He makes a case for delegate and even mentions C#. It seems to me that the time for bikeshedding the new name has passed.

1 Like

On the contrary: Rename `implied` to `delegate` by odersky · Pull Request #6649 · lampepfl/dotty · GitHub

So, it’s merged. We needed to do it before my ScalaDays talk tomorrow, hence the urgency. But everything is still subject to change. Over the next months we will use all of Dotty’s language features in our own code. That should give us good feedback, which might prompt some changes.

4 Likes

Forgive me if this has already been considered and discarded–if so, feel free to disregard. But what about instance as a keyword?

It’s been considered, but was thought to be confusing for being the same terminology as is sometimes used as an instance of a class.

Here is the slide with the list of names considered:

1 Like

Thank you for the pointer to the presentation. It does give a great explanation of the larger syntax changes replacing implicits, which I totally support. It will make Scala much easier. However no reason is given for the word “delegate” other than to state that the committee considered lots of words. He says that in the end it doesn’t matter as long as people can remember it. I strongly disagree. This matters. The choice of keyword has a huge impact on the ease of learning this feature. When I explain this feature to co-workers new to Scala I will say it is like a default instance of that type. They will be trying to figure out in what sense what thing is delegating to what other thing. They might ask: how is this like the design pattern? I will be forced to say: “it has nothing to do with the design pattern. Just pretend it says default”. There is no good reason for this burden of cognitive dissonance. Please reconsider. “implied”, “default”, “supplied”, or “provided” - any of these would be preferable. “default” is my favorite.

2 Likes