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:
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:
- “Proposal to Add Implied Instances to the Language”
Proposal to Add Implied Instances to the Language
- “Updated Proposal: Revisiting Implicits”
Updated Proposal: Revisiting Implicits
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?
- Could/should we “Remove Implicit Conversions” entirely?
Then also a very similar suggestion made by @jdolson here:
- Updated Proposal: Revisiting Implicits
- see also some immediately following posts on the subject
Martin has responded as follows:
- Updated Proposal: Revisiting Implicits
- 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,
Followup posts on this subject continue through December 10th.
How are conversions related to extensions?
“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) 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 – 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
abstract class, as proposed, or a
- Conversions don’t currently support path-dependence.
- Can this be addressed, should this be addressed?
- raised by @kai at:
- raised again by @kai somewhat later, here:
- Martin’s response:
- “Maybe… I personally don’t lose sleep over this”
- Can/should conversions be definable using macros?
- What about inline conversions?
- Conversion names cannot be overloaded, because they are now values rather than
methods. Is this a flaw?
- “Will the new encoding of type-parameterized implicit conversions
pose a performance issue?”
Alternative implicits proposal
There is also an alternative implicits proposal submitted by Eyal Roth; the overall discussion thread on that is here:
- Alternative proposal for implicits
Alternative proposal for implicits
And the section of the proposal specific to conversions is here:
- 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”.)
This topic will remain open for at least one month, to allow sufficient time to gather feedback.