On 2011-06-11 07:54:58 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
Consider two statements:
1. "I dislike Flag. It looks ugly to me."
2. "I dislike Flag. Instead I want named arguments."
There is little retort to (1) - it simply counts as a vote against. For
(2) the course of action is to point out the liabilities of changing
the language.
I'm actually not sure whether I want named arguments or not, but I'm
quite sure I don't want to use Flag!"" in my code. I'd actually prefer
a simple bool parameter to Flag!"".
Currently, it looks like we have these possibilities:
// definition // call with a constant
void func(bool abc); -> func(true);
enum Abc { no, yes }
void func(Abc abc); -> func(Abc.yes);
void func(Flag!"Abc" abc); -> func(Flag!"Abc".yes);
-> func(yes!"Abc");
-> func(Yes.Abc);
which then becomes this if you're using a boolean expression instead of
a constant:
// definition // call with an expression
void func(bool abc); -> func(expression);
enum Abc { no, yes }
void func(Abc abc); -> func(expression ? Abc.yes : Abc.no);
-> func(cast(Abc)expression);
void func(Flag!"Abc" abc); -> func(expression ? Flag!"Abc".yes :
Flag!"Abc".no);
-> func(expression ? yes!"Abc" : no!"Abc");
-> func(expression ? Yes.Abc : No.Abc);
-> func(cast(Flag!"Abc")expression);
My take on this is that we shouldn't try to reinvent the boolean in the
standard library. If you want to replace a bool with a two-option enum
at some places for clarity, that's fine. But I wouldn't elevate that to
a pattern meant to be used everywhere. And personally, I don't like the
proliferation of yes/no enums: if you use an enum, value names should
be more meaningful than a simple yes/no.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
