[swift-evolution] Ad hoc enums / options

[Austin Zheng]

Tuples are a structural type, they are described entirely by the fact that they are a tuple, plus their contained types.

Enum cases are not individual types; that precedent exists nowhere in Swift. You can't (yet) build a structural type out of something that isn't a type. The fact that you had to propose something like "AdhocEnumFitFill_2383748" as an autogenerated name for the type demonstrates the proposal's weaknesses: a tuple is an ad-hoc type that describes itself, while an anonymous enum isn't.

Now if enum cases were equivalent if they had the same name (like how "Int" means the same thing no matter what tuple or generic type it is used in), we'd have a good foundation for a self-describing structural type. But this isn't how the existing named enum types work. Why would it be a good idea to make anonymous enum cases interchangeable by name? Properties on different types aren't interchangeable, even if they have the same type. In fact, no type member that I am aware of is interchangeable solely on the basis of name. An "ArtistAction.Draw" and "CowboyAction.Draw" might have the same name, but they mean completely different things.

Finally, I have to ask: if you are updating your anonymous enum in multiple places, how much effort have you actually saved over a one-line enum definition? In fact, tuples are a great example of this: best practices usually state that they are good for ad-hoc destructuring, such as retrieving multiple return values from a function or pattern matching across several values at once, but structs are better used for almost everything else, since they carry semantic meaning that tuples don't.

I hope that clarifies my thoughts on the matter.

Best,
Austin


> On Jun 1, 2016, at 12:36 AM, Vladimir.S <svabox at gmail.com> wrote:
> 
> On 01.06.2016 9:55, Austin Zheng via swift-evolution wrote:
>> Maybe it's overkill. My personal opinion is that breaking the symmetry of
>> the language like this (are there any other types of function arguments
>> that cannot be passed as either variable values or literals?) is too much a
>> price to pay. Your library thinks it's being clever and vends its functions
>> as taking anonymous enum flags, and now there are a bunch of things I can't
>> do with those functions anymore.
>> 
>> A regular enum can be declared in one line anyways:
>> 
>> enum ScaleCropMode { case Fit, Fill }
> 
> Why do we have tuples? Struct could be defined by one line `struct SomeValue { var x = 0, y = 0 }` ;-)
> I.e. from my point of view developer should decide what he/she wants to use: ad-hoc enum or defined enum type *exactly* as now he/she can decide to use the same tuples in multiply functions instead of one defined struct type.
> 
> I replied regarding the variable on other message. (In short: I think of the same principle as for tuples: you can declare variable `let e: (.fill | .fit) = .fill` and use it)
> 
>> 
>> Austin
>> 
>>> On May 31, 2016, at 11:44 PM, Charles Constant <charles at charlesism.com
>>> <mailto:charles at charlesism.com>> wrote:
>>> 
>>> >  It breaks the ability to pass in a variable containing the desired
>>> value, rather than the literal value itself.
>>> 
>>> Maybe that's appropriate? If the caller is not passing in a hardcoded
>>> enum case, then that enum is probably general enough that it warrants a
>>> normal enum. But there are also situations where the same function is
>>> called from several files in the same code-base with different flags.
>>> Those are situations where it feels like overkill to clutter up my
>>> codebase with separate enums, only used by a single function.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tue, May 31, 2016 at 9:24 PM, Austin Zheng via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>    I admire the desire of this proposal to increase the readability of
>>>    code. I'm -1 to the proposal itself, though:
>>> 
>>>    - It breaks the ability to pass in a variable containing the desired
>>>    value, rather than the literal value itself. (Unless you actually
>>>    want a not-so-anonymous enum type whose definition happens to live in
>>>    a function signature rather than somewhere you'd usually expect a
>>>    type definition to live.)
>>>    - It breaks the ability to store a reference to the function in a
>>>    variable of function type (ditto).
>>>    - Almost every time I've wanted to use one of these "anonymous enums"
>>>    in my code, I've ended up needing to use that same enum elsewhere. In
>>>    my experience, 'lightweight enums' don't end up saving much time
>>>    compared to a full-fledged one.
>>> 
>>>    Like Brent said, I have to say no to any proposal that tries to make
>>>    enums synonyms for numerical values. What happens if you rearrange
>>>    your anonymous enum cases between library versions? Do you somehow
>>>    store an opaque case-to-UInt8 table somewhere for every anonymous
>>>    enum you define for resilience? What happens when people start
>>>    bringing back terrible C patterns, like doing arithmetic or bitwise
>>>    ops on the underlying case values? At least you have to try pretty
>>>    hard as it is to abuse Swift's enums.
>>> 
>>>    Austin
>>> 
>>>    On Tue, May 31, 2016 at 8:25 PM, Brent Royal-Gordon via
>>>    swift-evolution <swift-evolution at swift.org
>>>    <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>        > And the obvious answer is you can have up to 255 of these babies for the anonymous enum type, and be able to pass numerical equivalents UInt8 with compile time substitution. That the ad-hoc enumeration is basically a syntactic shorthand for UInt8, with an enforced upper bound compile time check simplifies everything including switch statements.
>>> 
>>>        If I wanted a language like that, I'd be writing C, not Swift.
>>> 
>>>        --
>>>        Brent Royal-Gordon
>>>        Architechies
>>> 
>>>        _______________________________________________
>>>        swift-evolution mailing list
>>>        swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>        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
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>