"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message news:isu15s$30as$1...@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.