On Wednesday, April 09, 2014 14:14:21 Andrei Alexandrescu wrote: > On 4/9/14, 11:14 AM, Jonathan M Davis wrote: > > On Wednesday, April 09, 2014 08:38:54 Andrei Alexandrescu wrote: > >> Too restrictive. What is a valid enum value? Would an enum flags need to > >> ascribe a name to every possible combination? > > > > Why is that too restrictive? I don't see how it even fundamentally makes > > sense for > > > > auto result = MyEnum.a | MyEnum.b; > > > > to result in a value of type MyEnum. > > One wants to call a function taking such an enum. -- Andrei
But it _isn't_ going to be a valid enum value. IMHO, a function which is taking or-ed flags where those flags are enums needs to take uint or ulong or whatever the base type of the enum is and _not_ the enum type. For instance, the fact that std.socket has functions which have a SocketFlags parameter is fundamentally broken, because the values passed aren't going to be valid values of SocketFlags unless you just so happen to pass only one of them rather than or-ing multiple. I don't see how it can be anything but broken when it's trivial to have variables of an enum type which aren't valid values for that enum type. That should require casting. And the fact that code like MyEnumString str = MyEnumString.foo ~ " bar"; compiles is just plain awful. As it stands, we can't even vaguely rely on a variable of an enum type actually being a valid value for that type, and I think that we should be able to rely on that barring a programmer screwing it up with casts. - Jonathan M Davis
