Flag proposal

[Nick Sabalausky]

Ignore this: I went to reply, hit the wrong key, and it sent before I got to 
type anything... The *real* reply in another post...

"Nick Sabalausky" <a at a.a> wrote in message 
news:isu4gg$5ff$1 at digitalmars.com...
> "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.
>>
>> 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
>
>