[swift-evolution] Anoymous Enums (Updated)

[Erica Sadun]

I don't believe character savings is the benefit. Stronger arguments are self-documentation in declaration, intrinsic switch support, clarity at call point, clarity of QuickHelp. All conversions from anonymous to fully qualified types involve refactoring, so I don't think this stands out as a particular issue. And I'm not convinced they need to have equivalent definition support.

As for documenting the meaning of low/med/high/extreme, no different than a standalone enumeration type. Not seeing the issue.

-- E


> On Feb 22, 2016, at 10:12 AM, David Waite <david at alkaline-solutions.com> wrote:
> 
> Having this work similar to other anonymous types would be an extension to the proposal. 
> 
> Other anonymous types can be considered equivalent by their definitions, e.g. (x:Int, y:Int) taken as input from one function can be passed to another. 
> 
> E.g. your adjustTemperature function wanted to call a checkSafety(device:DeviceType, [low | medium | high]:temperature) -> Bool function - could it?
> 
> what about if adjustTemperature took [low | medium | high | extreme]?
> 
> what about adjustTemperature having an internal var lastAdjustment:[low | medium | high] - would that work?
> 
> My concern is that there could many reasons to need to switch from shorthand/anonymous syntax to a full enum, and that switch will have the same fragility as changing a function from accepting a tuple to accepting a struct. If passing to another function or assigning to a variable would require a switch to a properly qualified enum, the feature seems not worth its character savings.
> 
> And I’m already unsure it is worth its existing character savings, especially once you start documenting the meaning of low / medium / high for other developers, and especially if you now have to do so for multiple functions rather than a single enum declaration.
> 
> -DW
> 
>> On Feb 22, 2016, at 9:46 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Feb 22, 2016, at 3:53 AM, Tino Heth via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I'm not sure wether I want to see that feature added, but I think there is a "structural" argument for it:
>>> We have anonymous functions (closures) and a (restricted) form of anonymous structs (tuples), so it would be consequent to have a anonymous variant for each fundamental entity in the language.
>>> I guess it is to late to establish a unified syntax for all of those, though…
>> 
>> I like the symmetry with the other anonymous types. This provides a highly focused tweak to Swift, with limited impact, and a measurable benefit to developers. (AKA the "Rule of Lattner")
>> 
>> Further, the values cannot be assigned to variables or passed as arguments as they have no "type".  I suspect it won't be hard to restrict them for being used with `Any` argument, limiting their use to flags and switch cases. If I'm conceptualizing this correctly, the benefits are clear and the consequences are small.
>> 
>> -- Erica
>> 
>>> On Feb 21, 2016, at 11:52 PM, Yong hee Lee via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>> please check the link below.
>>> 
>>> https://gist.github.com/erica/9148e2be916c7fae6f1e <https://gist.github.com/erica/9148e2be916c7fae6f1e>
>>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160222/3542edbc/attachment.html>