[SR-920] Re-design builtin compiler protocols for literal convertible types

[gribozavr]

Previous ID	SR-920
Radar	rdar://problem/25100871
Original Reporter	@gribozavr
Type	Improvement

Additional Detail from JIRA

Votes	17
Component/s	Standard Library
Labels	Improvement, AffectsABI
Assignee	None
Priority	Medium

md5: 9c9daaa0076abc9937d022ed16def26e

is duplicated by:

• SR-3317 Literal protocol for decimal literals should support precise decimal accuracy
• SR-3970 Rework ExpressibleBy(Integer|Float)Literal protocols

relates to:

• SR-7124 Double-rounding in floating-point literal conversion

Issue Description:

Swift aims to be an extensible language through the built-in compiler protocols, which allow user-defined types to adopt literal syntax.

If we want to commit to that design as ABI, we need to improve the protocols so that they are actually useful outside of the standard library.

1. There should be a type in the standard library that can represent the literal in a lossless way. For example, currently integer and floating point literals are truncated to the maximum precision supported by the library (Int64 and Float80) before they can be handled by user code.

For example, the library could provide an IntegerLiteral type, which wraps a 2048-bit integer that user types adopting the literal protocols could use. Same for floating-point literals (but the number should be represented exactly to allow decimal foating point literals).

2. Protocols related to string literals should have reasonable default implementations. Currently, to implement a string literal convertible type, you need to write many functions that just forward to each other to conform to the protocol.

3. When we get special transport types, the initializer labels can become simpler (e.g. drop the ‘literal’ from the label, since that would repeat type information).

[belkadan]

I'm pretty sure we can fix #2 with protocol extensions already, but #1 and #3 are interesting.

[belkadan]

I am concerned about using an APInt-equivalent for types that really don't need it. That's something we'd have to optimize out even at -Onone (-Odebug).

[gribozavr]

We're using Builtin.Int2048 for integer literals today anyway.

[bob-wilson]

I dup'ed SR-3970 here (Rework ExpressibleBy(Integer|Float)Literal protocols)

[tbkka]

As I just pointed out in a comment on SR-7124, there already is an answer for #1: String. The most direct, lossless way to pass around literals is in the exact textual form they appear in the program source code.

Of course, standard types (such as `Float` or `Int64`) should be parsed into constants at compile time, which requires the compiler to do some work with the token text. That requires the compiler to determine the type before it parses the textual token into a constant. In particular, it's not enough to know a token is `FloatLiteral`, due to the problems documented in SR-7124. The compiler should not parse the token `1.234` as Float or Double until it has actually identified the target type at which point it can use the associated `FloatLiteralType` to select the correct parse behavior.

[tkrajacic]

Is there any update on this?

This makes for such unfortunate `Decimal` behavior when initialized through a literal 🙁

See https://forums.swift.org/t/exact-nsdecimalnumber-via-literal/12834

[tkrajacic]

If this is an ABI breaking change, what does that mean for the Swift 5+ future? Will this never get fixed if it is not done for Swift 5? I mean the Decimal literals not being exact are a serious flaw imho.

/cc @belkadan

[belkadan]

It means we'd have to be careful about adding a new way to initialize decimal values in the future, and they might not backwards-deploy. It doesn't mean we can never do it.

It is unlikely to happen for Swift 5 at this point, since we are a month past the final branch. That doesn't mean development for Swift 5 is over, but it does mean new features for Swift 5 are pretty much over.

[amomchilov]

This needs to be higher priority, IMO. This feature is essentially broken, because besides the existing `Int`/`Double` types that exist, there's not much that this would be useful for. You can't use it for a `BigInt` library, which seemed like 99.9999% of the motivation behind this.

[belkadan]

The feature is not broken; it's absent. It'll be possible to do it in the future. Now that we're past the deadline where it could go into the initial ABI, there's not really any urgency over any other feature that people really want that isn't present yet.

[swift-ci]

Comment by Marcos Sánchez-Dehesa (JIRA)

I just want to add a +1 to express the need for this feature.

• I develop financial libraries and encoding/decoding `Decimal` from a JSON always requires to pass by a `String` (and many times I don't control the source of the information).

• [Matt|https://github.com/mattt]'s book [Guide to Swift Number|https://flight.school] is full of Caveats and warning signs for this error.