> - It breaks the ability to store a reference to the function in a variable
> of function type (ditto).
IMO the most important point. Probably we can have autogenerated names for
such enums like:
function : func f(e: (.fit | .fill))->String
type is : (AdhocEnumFitFill)->String
or with no pre-defined syntax for such enum(so can't be used as type in code):
(AdhocEnumFitFill_2383748)->String
or just
(_enum_2383748)->String
But in this case two functions with different AdhocEnum_xxxx should be
compatible between each other if cases exactly the same.
I.e. we should be able to write:
typealias MyFunc = func (x: (.fit | .fill))->String
// internally this will be (_enum_9823765)->String
let myfunc : MyFunc = f
Probably we could have such syntax for adhoc enums:
func f(e: enum(.fit, .fill)) {}
As for other questions, for myself, I use the analogue with tuples: if
function requires a tuple, you can define tuple variable by typing its
declaration manually. And you can have the same tuples in a number of
functions, instead of structs. Yes, you will need to change tuple variables
*anywhere* in your code if tuple in function declaration changed.
You have this freedom for tupes(ad-hoc structure). Why don't we need the
same for enums ?
On 01.06.2016 7:24, Austin Zheng via swift-evolution 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] <mailto:[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] <mailto:[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
