On 09/07/2011 10:49 PM, Jonathan M Davis wrote:
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.
final switch works the same with or without warnings. Basically final
switch is wrong in assuming that enumerations can only contain the
declared values, because the bitwise operators work on enums.
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;
It is not. But there is currently no nice way to express a set of
orthogonal flags. enumerations are mis-used for it sometimes, but as you
said that does not make sense. I sometimes have small bugs because the
alias is weakly typed though.
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 -
I'd argue that (MODEread | MODEwrite) is a single mode resulting from
the composition of the MODEread and MODEwrite modes.
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).
That is why imho Phobos should not use enums for file modes. They are
just not a good match, because the language is so confused about what is
valid on enums and what is not.
