Anoymous Enums (Updated)


(Yong hee Lee) #1

please check the link below.

https://gist.github.com/erica/9148e2be916c7fae6f1e


(Erica Sadun) #2

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 22, 2016, at 3:53 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 21, 2016, at 11:52 PM, Yong hee Lee via swift-evolution <swift-evolution@swift.org> wrote:

please check the link below.

https://gist.github.com/erica/9148e2be916c7fae6f1e


(David Waite) #3

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@swift.org> wrote:

On Feb 22, 2016, at 3:53 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

please check the link below.

https://gist.github.com/erica/9148e2be916c7fae6f1e

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #4

I don't believe character savings is the benefit. Stronger arguments are self-documentation in declaration, intrinsic switch support, clarity at call point, clarity of QuickHelp. All conversions from anonymous to fully qualified types involve refactoring, so I don't think this stands out as a particular issue. And I'm not convinced they need to have equivalent definition support.

As for documenting the meaning of low/med/high/extreme, no different than a standalone enumeration type. Not seeing the issue.

-- E

···

On Feb 22, 2016, at 10:12 AM, David Waite <david@alkaline-solutions.com> 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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 22, 2016, at 3:53 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

please check the link below.

https://gist.github.com/erica/9148e2be916c7fae6f1e

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #5

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…


(Shawn Erickson) #6

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@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@swift.org> wrote:

On Feb 22, 2016, at 3:53 AM, Tino Heth via swift-evolution < > swift-evolution@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@swift.org> wrote:

please check the link below.

https://gist.github.com/erica/9148e2be916c7fae6f1e

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #7

Under what circumstances could these ever escape scope?

-- E

···

On Feb 22, 2016, at 10:20 AM, Shawn Erickson <shawnce@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 22, 2016, at 3:53 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

please check the link below.

https://gist.github.com/erica/9148e2be916c7fae6f1e

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Shawn Erickson) #8

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@ericasadun.com> wrote:

Under what circumstances could these ever escape scope?

-- E

On Feb 22, 2016, at 10:20 AM, Shawn Erickson <shawnce@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@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@swift.org> wrote:

On Feb 22, 2016, at 3:53 AM, Tino Heth via swift-evolution < >> swift-evolution@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@swift.org> wrote:

please check the link below.

https://gist.github.com/erica/9148e2be916c7fae6f1e

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #9

"An enumeration that's used in more than once place, has associated or raw values, or provides semantics beyond use as a flag is not a suitable candidate for this proposal."

I'd suggest that self-documenting flags are in and of themselves sufficiently useful.

-- E

···

On Feb 22, 2016, at 10:32 AM, Shawn Erickson <shawnce@gmail.com> wrote:

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@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
Under what circumstances could these ever escape scope?

-- E

On Feb 22, 2016, at 10:20 AM, Shawn Erickson <shawnce@gmail.com <mailto:shawnce@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Feb 22, 2016, at 3:53 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

please check the link below.

https://gist.github.com/erica/9148e2be916c7fae6f1e

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Waite) #10

Then maybe low/medium/high is just a bad example?

···

On Feb 22, 2016, at 10:35 AM, Erica Sadun <erica@ericasadun.com> wrote:

"An enumeration that's used in more than once place, has associated or raw values, or provides semantics beyond use as a flag is not a suitable candidate for this proposal."

I'd suggest that self-documenting flags are in and of themselves sufficiently useful.

-- E


(Erica Sadun) #11

A few more off the top of my head. Any of these better?

func startService(type: [ client | server ]) { ... }
func pushNewContext(colorModel: [ rgba | rgb | grayscale ] ) { ... }
func animateDrawer(toState: [ closed | open | hidden ] ) { ... }
func startRecordingAudio(quality: [ q8k | q44k | q22k ] ) { ... }
func performAlert(type: [ slidein | pop | flip ] ) { ... }
func createPath(style: [ closed | open ] ) { ... }
func rectifyImage(standard: [ uikit | exif ]) { ... }

-- E

···

On Feb 22, 2016, at 10:57 AM, David Waite <david@alkaline-solutions.com> wrote:

Then maybe low/medium/high is just a bad example?

On Feb 22, 2016, at 10:35 AM, Erica Sadun <erica@ericasadun.com> wrote:

"An enumeration that's used in more than once place, has associated or raw values, or provides semantics beyond use as a flag is not a suitable candidate for this proposal."

I'd suggest that self-documenting flags are in and of themselves sufficiently useful.

-- E


(Brent Royal-Gordon) #12

A few more off the top of my head. Any of these better?

Frankly, I don't think so.

func startService(type: [ client | server ]) { ... }

Isn't this mixing two operations into one call which are either barely related, or probably need to be parameterized with the service type?

func pushNewContext(colorModel: [ rgba | rgb | grayscale ] ) { ... }

The context doesn't have a colorModel property?

func animateDrawer(toState: [ closed | open | hidden ] ) { ... }

There's no self.drawerState property?

func startRecordingAudio(quality: [ q8k | q44k | q22k ] ) { ... }

You don't pass this through to your audio file model?

func performAlert(type: [ slidein | pop | flip ] ) { ... }

The animation isn't performed by a method on the type?

func createPath(style: [ closed | open ] ) { ... }

There's no style property on the path you created?

func rectifyImage(standard: [ uikit | exif ]) { ... }

Why is this one method if it has two almost completely different code paths?

This is a clever feature, but the more examples I see, the more convinced I become that every use smells of poorly structured code.

(Plus, it doesn't support the one place where we genuinely *do* often have an ad-hoc group of cases which is different for every call: option sets.)

···

--
Brent Royal-Gordon
Architechies


(Erica Sadun) #13

I think we're seeing the world through two different eyes: big programming and little programming.
In big programming, everything is well architected, meant for re-use, well-documented, and probably
developed within a highly structured environment. In little programming, someone writes a utility here
or there, or creates a quick library that some friends can use.

A strong programming language supports both. Not everything in Swift needs to be fully structured, fully
organized, fully realized, although these are goals that should never be fully ignored. And yes, I see the
same potential as you for architecting out these use-cases for big projects. I also see the convenience in
offering switch-cases for small ones.

-- E

···

On Feb 22, 2016, at 8:31 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

A few more off the top of my head. Any of these better?

Frankly, I don't think so.

func startService(type: [ client | server ]) { ... }

Isn't this mixing two operations into one call which are either barely related, or probably need to be parameterized with the service type?

func pushNewContext(colorModel: [ rgba | rgb | grayscale ] ) { ... }

The context doesn't have a colorModel property?

func animateDrawer(toState: [ closed | open | hidden ] ) { ... }

There's no self.drawerState property?

func startRecordingAudio(quality: [ q8k | q44k | q22k ] ) { ... }

You don't pass this through to your audio file model?

func performAlert(type: [ slidein | pop | flip ] ) { ... }

The animation isn't performed by a method on the type?

func createPath(style: [ closed | open ] ) { ... }

There's no style property on the path you created?

func rectifyImage(standard: [ uikit | exif ]) { ... }

Why is this one method if it has two almost completely different code paths?

This is a clever feature, but the more examples I see, the more convinced I become that every use smells of poorly structured code.

(Plus, it doesn't support the one place where we genuinely *do* often have an ad-hoc group of cases which is different for every call: option sets.)

--
Brent Royal-Gordon
Architechies


(Erica Sadun) #14

So, after sleeping on this, should it? Should this proposal be about option sets and not enums per se? Since the primary use case is flagging? Or support
both enums for boolean replacement and option sets for more complicated flags?

-- E

···

On Feb 22, 2016, at 8:31 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
(Plus, it doesn't support the one place where we genuinely *do* often have an ad-hoc group of cases which is different for every call: option sets.)