search

swiftlang / swift

The Swift Programming Language
https://swift.org
Apache License 2.0
67.18k stars 10.32k forks source link

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

Open gribozavr opened 8 years ago

gribozavr commented 8 years ago
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:

relates to:

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 commented 8 years ago

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

belkadan commented 8 years ago

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 commented 8 years ago

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

bob-wilson commented 6 years ago

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

tbkka commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

Comment by Marcos Sánchez-Dehesa (JIRA)

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