Proposal: Changes to Implicit Conversions

Scala Improvement Process
1

Proposal: Changes to Implicit Conversions

Hello Scala Community!

This thread is the SIP Committee’s request for comments on a proposal to change how implicit conversions work in the language.

Summary of the proposal

Scala 2 already has implicit conversions, which are implicitly available instances of scala.Function1 (or “[methods] convertible to a value of that type” SLS 7.3). In short, this proposal adds a class scala.Conversion to the standard library, as a subtype of Function1. Implicit conversions are changed to be given instances of the new type. No new syntax is required. Old-style conversions will be phased out. A language flag will be required in order to either define or use “undisciplined” conversions, that is, conversions between types defined elsewhere.

This is one of a set of proposals that are collected under “Contextual Abstractions” in the Dotty docs.

This proposal and the others are motivated, together, in this section:

And then further material specific to conversions only is here:

Related discussions

Note: To channel discussions, we are dealing with the individual “Contextual Abstractions” proposals in separate threads. But it would be good to read and absorb all proposals there together before discussing individual parts.

The most relevant other discussions in this area are:

Note that both of these topics have now grown very long (632 posts and counting). But also, “I believe we are on the home stretch”, says Martin, so it’s appropriate to now also consider side topics such as conversions.

Because the various “Contextual Abstractions” proposal aren’t entirely independent of each other, the topic of conversions has already been touched upon repeatedly in the above threads. The following sections summarize and link to those sub-discussions.

Should conversions always be explicit?

This suggestion has been made at least twice, by @jdegoes and @jdolson:

Then also a very similar suggestion made by @jdolson here:

Martin has responded as follows:

  • Updated Proposal: Revisiting Implicits - #171 by odersky
  • He writes: “I agree that a typeclass for explicit conversions via as would be useful”, but it’s unclear if he believes this typeclass (he suggests calling it Convertible) would exist in addition to, or instead of, Conversion.

@morgen-peschke notes that he has already made use of such a typeclass; see Updated Proposal: Revisiting Implicits - #177 by morgen-peschke

Followup posts on this subject continue through December 10th.

How are conversions related to extensions?

This was raised by @Ichoran at Updated Proposal: Revisiting Implicits - #216 by Ichoran

“I don’t feel that extensions are sufficiently unified with conversions, which can do exactly the same thing according to the docs. Either conversions shouldn’t allow you to call methods (i.e. a method call would not be a request to convert the type), or the unification should be clearer. In particular, all the extensions should be instances of Conversion…”

Martin was dismissive (“I think we are pretty much settled on the current design” of extensions). But there was some followup discussion about extension method syntax, which seemed to be shut down by Seb’s conclusion: “We should indeed forbid to call extension methods as if they were normal methods” (Updated Proposal: Revisiting Implicits - #224 by sjrd) A few further posts followed, ending on January 8.

This thread of discussion was somewhat revived by @morgen-peschke in early February, in messages such as Updated Proposal: Revisiting Implicits - #349 by morgen-peschke – it wasn’t clear to me if this was directly applicable to the other questions about the design of conversions, or whether the Convertible typeclass was just being used as an example of bringing out broader issues around the overall implicits design.

Other conversions questions so far

Alternative implicits proposal

There is also an alternative implicits proposal submitted by Eyal Roth; the overall discussion thread on that is here:

And the section of the proposal specific to conversions is here:

For discussion

  • Is the proposal clear?
  • Should this proposal be accepted by the committee for Scala 3?
  • Should the proposal be modified before acceptance?
  • Naming. Are we to call these conversions “given conversions” now? (Currently the doc still says “implicit conversions”.)

Time frame

This topic will remain open for at least one month, to allow sufficient time to gather feedback.

6 Likes