Flag proposal

[Andrei Alexandrescu]

On 6/10/11 3:34 PM, Michel Fortin wrote:
> On 2011-06-10 16:10:51 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> On 6/10/11 2:12 PM, Michel Fortin wrote:
>>> I have to say I totally agree with Robert.
>>>
>>> I agree with the need for a way to name parameters, but instantiating a
>>> pseudo-boolean type from a template for each function parameter is worse
>>> than the initial problem. Templates are already a difficult concept to
>>> grasp for most people (because they're so abstract), we really don't
>>> need to replace every boolean parameter with a template type.
>>
>> I disagree with the "templates are difficult" mantra. It is a meme
>> from C++ much like "macros are evil" are one from C. It's a simple
>> construct, you use it.
>
> Neither C macros nor C++ or D templates are very difficult by
> themselves. People trying to do unintuitive but clever things with them
> earned them this reputation.

See, here you're simply wrong. C macros are heinously complicated in 
definition, and heinously complicated to implement. C++ templates are 
very bulky in definition too. It's not worth your time you argue this 
further.

> If you want something to be used everywhere and it is not an
> implementation detail, make it part of the language. Implementing what
> sounds should be a language feature through a template hack and putting
> it the standard library is not going to make people feel good about the
> language, it'll remind them of what the language is missing.

The problem with the "hack" label is that it instantly decreases the 
level of the conversation. It's the "N" word of programming.

I don't want a universal thing, I want to solve a simple problem: there 
are 7 yes/no enums in Phobos, and probably some more to come. Flag 
solves that problem in a reasonable way. This is pretty much it.

>>> And just try to think of the signature for the function above if it was
>>> using Flag!
>>>
>>> void foo(Flag!"param" param, Flag!"otherParam" otherParam,
>>> Flag!"thisOneIsntRequired" thisOneIsntRequired =
>>> Flag!"thisOneIsntRequired".no);
>>>
>>> Do we really want to expose that in the documentation?
>>
>> Yes, that's the whole point, though I agree the hiccup in the default
>> initializer is annoying.
>
> I find it funny that you see a hiccup only in the default initializer
> when the name of all parameter is also duplicated in its type. Shouldn't
> that be 4 hiccups?

I don't think so, but I understand how you can frame that as an argument 
that supports your viewpoint.

>> The documentation doesn't need the names anymore; the user would just
>> say:
>>
>> void foo(
>> Flag!"compressed",
>> Flag!"encrypted",
>> Flag!"buffered" = Flag!"buffered".no);
>>
>> Save for the "ehm" default parameter this looks palatable to me.
>
> Does that mean we now need a language feature to tell the documentation
> generator not to emit attribute names for parameters of type Flag!"" ?

No, just version(ddoc) for select functions if you want them to. You 
have the needed means within the language.


Andrei