Proposal to Add Implied Instances to the Language

Scala Improvement Process
145

Thank you all who have contributed suggestions and critique.

Here’s what I took back from the discussion so far (on all three threads covering revised implicits).

  • Many people feel that the changes are too radical for the benefits they bring. I continue to believe that the benefits justify the proposed changes.

  • Various improvements to the proposal were suggested. I’d like to comment on some of them further:

    • I think we have reached consensus that given should come last in an instance definition.
    • We have also reached consensus that tooling should be improved so that suggestions for
      missing imports can be made when an implicit is not found.
    • There was a proposal by @tarsa to change the application syntax from (a given b) to a.given(b). I like that, but in the end decided to not pursue this, since we don’t have precedence for a keyword being used as a method. By contrast we do have precedence for keywords used in infix position, such as match.
    • I am still on the fence whether we want to restrict given in method definitions so that given parameters cannot be followed by normal parameters. The restriction is technically unnecessary, and the idiom has some use cases. The use cases can be worked around at the price of some more complication, and possibly some run-time cost. The only reason to restrict is that the syntax of given followed by normal parameters looks weird. One argument in favor of leaving it in is that weird looking syntax is its own regulative. People would hopefully use it only if it’s strictly necessary, which means almost never. Overall, I could live with either leaving it in or removing it.

The most widely debated point was (again!) what keywords to use for instance definitions. I believe it is very important to get this right. And it’s frustrating that this seems so hard. There are three choices that I want to comment on.

  • The current proposal: implied ... for. Received quite a lot of criticsm including from people who have used it intensively.
  • The smallest change: implicit ... for. Since it’s closest to current usage it would probably have the least resistance from existing users. I still think it’s a possibility, in the sense that it is better than the status quo. But it’s not as good as it could be. First, implicit ... for is a weird formulation, only tolerable because we are already used to contorsions of the word implicit (and implicit ... of would make even less sense). But it would look strange to a newcomer. Second, it risks confusing people further by not clearly distinguishing between old and new style syntax for implicits.
  • The “correct” word: repr ... of. We got some support that representative is a good word for the term that’s inferred for a type. And representative of … is correct English. repr as an abbreviation works OK, except that it’s a bit hard to pronounce.

My conclusion from these discussions is that I propose to switch to the repr ... of syntax for instance definitions. Since this thread has already gotten 140+ replies, I propose to close it, and replace it with the new proposal.

3 Likes