Semi-serious question for integer literals in particular: do we need a separate 
protocol at all?  Are there types we want to support where integer literals 
should be supported, but + doesn't make sense?  Where 1+1 actually isn't 2?

If not, are integer literals really just part of Arithmetic?

- Steve

> On Jun 28, 2016, at 11:21 PM, Sean Heber via swift-evolution 
> <[email protected]> wrote:
> 
> IntegerLiteralExpressable?
> 
> Does Apple employ any philosophers? We might need one...
> 
> l8r
> Sean
> 
> Sent from my iPad
> 
>> On Jun 28, 2016, at 10:02 PM, Erica Sadun <[email protected]> wrote:
>> 
>> 
>>> On Jun 28, 2016, at 8:08 PM, Sean Heber <[email protected]> wrote:
>>> 
>>> What about..
>>> 
>>> Syntax.ConvertibleFromIntegerLiteral
>>> etc..
>> 
>> I like it but Dave has already expressed that this isn't conversion. This
>> is something distinct, magical, and more importantly, ineffable.
>> 
>> He says it means an instance of the type can be written as a literal, and
>> not converted from a literal. He writes:
>> 
>>> 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
>>> }
>> 
>> So we're looking at something more like:
>> 
>> Syntax.AnIntegerLiteralCanBeSubstitutedForThisTypeAndTheCompilerWillNotBarf
>> 
>> -- E
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to