[swift-evolution] Ad hoc enums / options

Charles Constant charles at charlesism.com
Wed Jun 1 01:44:19 CDT 2016


>  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> 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> 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
>> 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/20160531/b438e8cf/attachment.html>


More information about the swift-evolution mailing list