[swift-evolution] Anoymous Enums (Updated)

[Shawn Erickson]

Likely not the best wording on my part... It by definition can't escape but
the coder may find they need it to conceptually escape / persist which then
leads to mapping it to some other form that captures the same or similar
state.

Anyway I meant to say I like it and generally support the addition. I only
question if the utility of it may be too limited.

I will play around in code examples to better clarify my thinking on this.

On Mon, Feb 22, 2016 at 9:22 AM Erica Sadun <erica at ericasadun.com> wrote:

> Under what circumstances could these ever escape scope?
>
> -- E
>
> On Feb 22, 2016, at 10:20 AM, Shawn Erickson <shawnce at gmail.com> wrote:
>
> I have similar concerns as David. I do like the idea but I see it becoming
> a problem in not a typical usage as David outlined. You likely would never
> want to use this in any public API or possibly any function signature for
> that matter (again given the limits implied by the short hand). I see it
> being useful in a given scope of code for the purpose of readability and
> even safety. It is when it starts to escape that scope it become less
> useful and possibly unsafe.
>
> On Mon, Feb 22, 2016 at 9:12 AM David Waite via swift-evolution <
> swift-evolution at swift.org> 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> wrote:
>>
>>
>> On Feb 22, 2016, at 3:53 AM, Tino Heth via swift-evolution <
>> 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> wrote:
>>
>>
>> please check the link below.
>>
>> https://gist.github.com/erica/9148e2be916c7fae6f1e
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> 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/0ac4e438/attachment.html>