Flag proposal

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:isu15s$30as$1 at digitalmars.com...
> On 6/10/11 3:34 PM, Michel Fortin wrote:
>> 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.
>

You're assuming that we're choosing the word "hack" as an attempt to sway. 
Not so. We're calling it a hack because we genuinely see it as such.

However, I can see how the accusation that our usage of "hack" was an 
attempt to sway with wordplay (or any other such resorting to 
meta-arguments) can be used to frame an argument that supports your 
viewpoint.

> 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.
>

Others *do* want a more universal thing.

>>>> 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.
>

Now who's digging their heels in and just being stubborn? You *really* don't 
see the problem with "Flag!"param" param"?

>>> 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.
>

And with named arguments, you don't even need to bother with that. So, more 
verbosity (and likely an indentation increase) to support (minimally) "less" 
verbosity.