Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
gribozavr opened this issue Mar 11, 2016 · 11 comments
Open

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

gribozavr opened this issue Mar 11, 2016 · 11 comments

Comments

@gribozavr
Copy link
Collaborator

@gribozavr gribozavr commented Mar 11, 2016

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
Copy link
Contributor

@belkadan belkadan commented Mar 11, 2016

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

@belkadan
Copy link
Contributor

@belkadan belkadan commented Mar 11, 2016

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
Copy link
Collaborator Author

@gribozavr gribozavr commented Mar 11, 2016

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

@bob-wilson
Copy link

@bob-wilson bob-wilson commented Aug 30, 2017

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

@tbkka
Copy link
Contributor

@tbkka tbkka commented Apr 13, 2018

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
Copy link

@tkrajacic tkrajacic commented Dec 8, 2018

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
Copy link

@tkrajacic tkrajacic commented Dec 19, 2018

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
Copy link
Contributor

@belkadan belkadan commented Dec 19, 2018

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
Copy link

@amomchilov amomchilov commented Dec 22, 2018

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
Copy link
Contributor

@belkadan belkadan commented Jan 7, 2019

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
Copy link
Collaborator

@swift-ci swift-ci commented Aug 28, 2019

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.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants