[swift-evolution] [Discussion] Enum Leading Dot Prefixes

[Erica Sadun]

Dany,

I've already updated my working copy of the proposal to change that to not requiring the leading dot based on feedback.

-- E

> On Feb 14, 2016, at 6:24 AM, Dany St-Amant via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> Le 13 févr. 2016 à 15:29, David Waite via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> Erica,
>> 
>> The current spec has the following line:
>> 
>>> static func staticFunc2() { let foo = .Tails } // requires leading dot
>> 
>> The leading dot requirement does not exist today for references to static properties and functions from a static function.
> 
> After focusing on this line and on the error we get back when trying it now in playground, I no longer see the reported inconsistent as such, but just as a clash of two permissible syntax, which if changed as proposed will just swap an inconsistency for another one.
> 
> For those wondering, the reported error is: type of expression is ambiguous without more context
> 
> The shorthand syntax is to be used when the compiler, and the programmer knows what the type is. In the above example, why should the compile infer that variable foo is of type Coin. It would make more sense for that particular function to be:
> 
> static func staticFunc2() { let foo = Coin.Tails }
> static func staticFunc2() { let foo:Coin = .Tails }
>  
> And be consistent with (both at a global scope or as static inside the enum):
> 
> let firstCoin:Coin = .Heads
> let secondCoin = Coin.Tails
> let thirdCoin = .Heads // not allowed
> 
> The apparent inconsistency seems to stem from the compiler doing an implicit equivalent of:
> 
> let heads = Coin.heads
> let tails = Coin.tails
> 
> If one define these on its own at a global level, the same inconsistent use of the leading dot is present everywhere.
> 
> I’m thinking that the proposal as stated "mandate leading dot" is wrong, it should be redone as "prevent direct access to the implicit static let auto-generated for the enum case within the enum declaration". Unfortunately, I do not know if there are legit use of this implicit static let in the wild.
> 
> This way, for the staticFunc2 we get:
> 
> static func staticFunc2() { let foo = Coin.Tails }  // Acceptable
> static func staticFunc2() { let foo:Coin = .Tails } // Acceptable
> static func staticFunc2() { let foo = Tails }  // New error, no longer accessible
> static func staticFunc2() { let foo = .Tails } // Current error, ambiguous
> 
> 
> Dany
> 
>> Is your proposal to:
>> - require a dot in front of static properties/functions in this case as well for consistency across all static things
>> - require a dot only in front of the case statements, to promote consistency only for use of cases within an enum
>> - or, do you wish to change your mind about this particular case?
>> 
>> -DW
>> 
>>> On Feb 13, 2016, at 12:31 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> No. The wildcard match does not require a dot prefix.
>>> 
>>> -- E
>>> 
>>> 
>>>> On Feb 13, 2016, at 10:40 AM, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> I am assuming there would be no dot in front of _? 
>>>> 
>>>> 
>>>> switch value {
>>>> 	case .A: “A”
>>>> 	case .B: “B”
>>>> 	case ._:”D” // this is not correct?
>>>> }
>>>> 
>>>> 
>>>>> On Feb 13, 2016, at 9:18 AM, Joseph Lord via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> +1
>>>>> 
>>>>> Didn't even know it was legal. Definitely increases consistency and simplifies the language. 
>>>>> 
>>>>> J
>>>>> 
>>>>> On Feb 12, 2016, at 3:00 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>>> https://gist.github.com/erica/e0b8a3a22ab716a19db4 <https://gist.github.com/erica/e0b8a3a22ab716a19db4>
>>>>>> 
>>>>>> Requiring Leading Dot Prefixes for Enum Instance Member Implementations
>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160214/2f5b16c1/attachment-0001.html>