From: Moore, Paul (paul.moore_at_[hidden])
Date: 2001-03-06 04:24:18
From: David Abrahams [mailto:abrahams_at_[hidden]]
> I'm not fond of this proposal, because it forces people
> into long-winded usage. Also, iterator_traits<Base> are
> seldom going to be correct, are they? Maybe it's too
> tricky, but I'm sure with enough metaprogramming you could
> get it to detect whether any of the /currently existing/
> parameters are built traits using the named parameters
> technique, and begin extracting trait values from there.
> My point is that people who just want to target conforming
> compilers ought to be able to work with the current
> (terse) usage... and I guess this also argues for moving
> the Pointer parameter to the back again, once we also have
> your new technique.
I've been lurking through this discussion, not 100% sure I understood what
is going on, but a little worried. Dave's comments seem to bring my thoughts
into focus. A apologise in advance if I've missed the point here...
It seems to me that the intent is to simulate named parameters for templates
which have a number of (relatively) unrelated arguments. While this is not a
problem to me in principle, I feel that the following points are important
1. C++ doesn't have named parameters. Any method for simulating them must of
necessity be clumsier than a built in language construct. This clumsiness
will be visible to the user.
2. Even in languages with named parameters, they are not always used.
Personal preference and/or application requirements (for clarity of code)
have a significant impact on the decision.
As such, I feel that it is important to ensure that in simulating the
ability to call of f(a,b,c) [I'm using functions rather than templates here
to keep the example simple, not because I believe that this discussion is in
any way related to function calls!!!] as f(a=1, b=2, c=3) or f(c=2) or
f(c=1, a=2), we must make sure NOT to lose the ability to call it as
f(1,2,3) or even f(1,2).
My understanding of Dave's point is that the f(1,2) usage has been lost.
My personal view is that I would (nearly always) use the positional usage,
rather than the named parameter usage, mainly for consistency with the rest
of the language. Hence, if the iterator adaptors library forced me to use
named parameters, I would have an annoying and difficult learning/acceptance
curve to climb.
While the technique is certainly clever, let's not get overly impressed by
the cleverness, at the expense of consistency and simplicity.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk