On 6/10/11 3:34 PM, Michel Fortin wrote:
On 2011-06-10 16:10:51 -0400, Andrei Alexandrescu
<seewebsiteforem...@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
