Favour error over implicit conversions with generic number literals

[bishabosha]

Currently, if we do something like val x = 0xcafebabe: BigDecimal, then we get a BigDecimal after some implicit conversion from an Int, because there is no instance of FromDigits.WithRadix[BigDecimal], as decimals only work with base 10. Someone may find this surprising when using the explicit type ascription to implement a custom number type.

• This PR introduces inline summoner methods used to ensure that a given FromDigits[T] is of the correct subclass, (WithRadix, Decimal or Floating) else issue a compile time error.
• The desugaring in Typer now calls these summoner methods with the target type T and then calling fromDigits on the result, which will cause a compile time error if the FromDigits[T] is of the incorrect subtype, rather than silently dropping to the default Int or Double interpretation.
• The summoners are implemented in the standard library so user code may use them for other metaprogramming features such as string interpolators.

Alternatives

• Implement fully in typer, but can not be used by other library code.
• Use a macro on summoners with arguments of type FromDigits[T], this relies on macro subtype-checks to get a precise type, so does not appear in the signature - this allows a custom error message without synthesising a temporary given if one does not exist.
• [Current Implementation] Avoid a macro and use more precise types on the summoners' given parameters, whilst adding implicitNotFound messages to the subtypes of FromDigits and calling the summoners after proving there is already a given instance in scope of just FromDigits[T]. This would mean library code users would have to synthesise a given to get the same error.

[odersky]

The PR should also update the doc page to reflect what is implemented.

[bishabosha]

I've updated the docs

[odersky]

I believe this is not enough. For instance, it is said that the companion object defines a method fromDecimalDigits but it is not specified where and when this method is called.

I believe if we want to this to go ahead, it needs a complete rework of the doc page, and the SIP committee has to decide on the changes. My concern is that once the additions are fully worked in, we might decide that things became too complex.

[odersky]

One possibility is to put this on hold until the SIP committee has had a chance to go over it.

[bishabosha]

I've updated the doc page to list when each summoner method is used, as a stand in until rewriting.

[bishabosha]

I've update the documentation again, I believe that it is easier to read, and it also incorporates the motivation for this change as a safety feature.

[rjolly]

I do not see it as a problem if numeric literals get converted to whatever possible type by implicit conversion. On the contrary, I think it would be a nice feature if the system was re-implemented in terms of implicit conversion. A numeric literal would be encoded as some hidden type (corresponding to FromDigits and subtraits as suited) and there would be an implicit conversion from the hidden type to the target type. This would allow numeric literals to take part in any chain of implicit conversions one could imagine, for instance in cases like:

18446744073709551616 + BigInt(1) // currently fails
BigInt(1) + 18446744073709551616 // succeeds

Edit : implicit conversion from literal to BigDecimal would make implicit conversion from Int to BigDecimal unnecessary. Consequently we could dispose of it, and the problematic example val x = 0xcafebabe: BigDecimal would vanish, because the needed conversion would be from some WithRadix.Literal to BigDecimal and it would not exist.

[odersky]

Closing for now. To be revived when we come to to generic number literals.

[SethTisue]

label t:on-hold?