Re: [boost] Re: Re: Policy-based smart pointers revisisted (was: Re:Preliminarysubmission: command line & config file library)

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-19 13:53:14

"Edward Diener" <eddielee_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote...
>> "Edward Diener" <eddielee_at_[hidden]> writes:

>> > Nonetheless I do favor a compiler change such as allowing the "default"
>> > keyword to be used instead as Mr. Terekhov suggested in that same thread.
>> > That would be much cleaner and should be easy for any compiler to handle.
>> > This is one case where I would like to see the language updated with such an
>> > easy, transparent solution to the problem. Of course if others don't see it
>> > as much of a problem, they wouldn't be in favor of the solution since it
>> > involves the dreaded "C++ language change"
>>
>> Oh, it's a problem alright, but I'm still not very convinced of that
>> solution.  The problem with interfaces that have lots of positional
>> parameters is that you forget what the different positions mean.  To
>> solve that problem, you need either named parameters or a
>> position-independent interface.
>
> Since the C++ language already has embraced positional parameters as
> its normal means of passing information to functions, classes, or
> templates, it is a little disingenuous to complain about them.

Do you know the meaning of "disingenuous"?  Did you really mean to
accuse me of intellectual dishonesty?

> Every function call is essentially a matter of knowing "what the
> different positions mean". Since we are stuck with this metaphor, so
> to speak, we can at least make the best of it in regard to default
> parameters with a simple solution.

I think you're way off base.  To begin with, I'm not complaining about
positional parameters; I'm saying that they don't work well when there
are many.  Secondly, we're not neccessarily "stuck with this
metaphor".  Once the possibility of making language extensions arises,
we have lots of freedom to choose different approaches.

> I wouldn't mind the idea of named parameters so much other than the
> adjustment away from what every C++ programmer has previously become
> accustomed to using. I imagine the compilers would also get more
> complicated as another area for dealing with C++ identifiers would
> have to be dealt with. Simply adding "default" in order to invoke
> the default value for a particular position is so much easier.
>
> My point is: since we already deal with "positions" in nearly
> everything, why not add "default" as has been suggested. If the
> language evolves to named parameters or some other means of a
> position-independent interface for passing normal parameters, we can
> consider these other ideas for passing default values. Keeping the
> metaphor consistent ( KTMC as opposed to KISS <g> ) seems to me to
> be the best idea for now. That's not to say that you or others
> shouldn't invent better means, if you think it worthwhile, given
> what the language currently offers.

It doesn't matter what the best idea "for now" is, unless you take a
*very* long view of "now", and in that case there's plenty of time to
design a better approach.  The next standard won't come out for a few
years at least, and then we'll be stuck with that for another 10 years
or so.  It's hard enough to add any core language change that I don't
want to invest time in something which solves only half the problem.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution