> 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 < [email protected]> 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 < > [email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
