[swift-evolution] [Proposal Draft] Literal Syntax Protocols

Dave Abrahams dabrahams at apple.com
Tue Jun 28 19:13:43 CDT 2016


on Tue Jun 28 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

>> On Jun 28, 2016, at 2:57 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> No, it's exactly the opposite, as I keep saying.  Conformance to this
>> protocol does *not* mean you can initialize the type with a literal.
>> Proof:
>> 
>
>>  func f<T: IntegerLiteralConvertible>() -> T {
>>    return T(integerLiteral: 43) // Error
>>    return T(43)                 // Also an Error
>>  }
>> 
>> It means an instance of the type can be *written* as a literal:
>> 
>>  func f<T: IntegerLiteralConvertible>() -> T {
>>    return 43   // OK
>>  }
>> 
>> Everybody's confused about the meaning of the protocol, and doesn't like
>> the proposed names because they imply exactly the actual meaning of the
>> protocol, which they misunderstand.
>
> Or we're clueless AND it's a bad name.

It's possible, but until we have an objective rationale for why it's bad
(arguments that it seems to imply what turns out to be the actual
meaning of the protocol don't count!), *and* a better alternative, it's
sort of moot.  If you don't like `Syntax.IntegerLiteral` or
`Syntax.IntegerLiteralExpressible` then I'm out of suggestions.

> func f<T: IntegerPromotion>() -> T {
>     return 42 // the answer to everything
> }

Promotion means something very different; something that we actually
expect to incorporate into the language one day.

-- 
Dave


More information about the swift-evolution mailing list