On Wednesday, September 07, 2011 14:16:55 Timon Gehr wrote:
> On 09/07/2011 01:42 PM, Jonathan M Davis wrote:
> > On 09/07/2011 01:27 PM, Timon Gehr wrote:
> >> Oh, btw:
> >>
> >> final switch(Mode.read|Mode.write){
> >>
> >> case Mode.read: writeln(1); break;
> >> case Mode.write: writeln(2); break;
> >>
> >> }
> >>
> >> => 2
> >>
> >> hm...
>
> Actually, it will print nothing, not even an Assertion failure, my enum
> definition was wrong
Did you compile with -w? I don't remember if that affects final switch or not,
but there's definitely a problem if you can get final switch to take a value
that it doesn't handle without using a cast.
> > Personally, I don't think that&ing or |ing enums should result in an
> > enum, and this case illustrates one reason why. But ultimately, the
> > main issue IMHO is that&ing or |ring enums doesn't generally result in
> > a valid enum value, so it just doesn't make sense.
>
> Yes exactly. That is why I always use
>
> alias int MODE;
> enum:MODE{
> MODEread=1,
> MODEwrite=2,
> }
And how is that any different from
alias int MODE;
enum MODEread = 1;
enum MODEwrite = 2;
They're manifest constants, not enum values. So, you're basically suggesting
that flags be done with manifest constants as opposed to enums? That doesn't
encapsulate as well IMHO, and I'd still object to a function having a MODE
parameter, since that implies that a MODE is a single flag, whereas it's a
group of flags - that and as far as Phobos goes, we don't generally use aliases
like that (of course, we don't name types in all caps or start variable or
enum value names with uppercase characaters either, so what Phobos does
obviously isn't necssarily what you stick to).
- Jonathan M Davis
