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

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).

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

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

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.

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

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

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.

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.

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.

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.