You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SR-7124 Double-rounding in floating-point literal conversion
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).
The text was updated successfully, but these errors were encountered:
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.
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.
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.