Flag proposal

[Jonathan M Davis]

On 2011-06-10 16:46, Andrei Alexandrescu wrote:
> On 6/10/11 6:26 PM, bearophile wrote:
> > Andrei:
> >> That's good evidence that introducing named parameters would be
> >> quite involved.
> > 
> > It's also good evidence that Martin Odersky, one of the most
> > intelligent language designers alive today, is willing to do a lot to
> > support named arguments in his language :-)
> 
> I have all respect for Odersky's competence, but that is beside the
> point. Design decisions are always taken in a context, and it's not
> impossible he would've had decided otherwise in a different context.
> 
> D is a rich, powerful language _now_. It has classic features present in
> many languages, and a few features that are not present in many. Their
> full combination is not present in any other language, and creates a
> unique context.
> 
> We've been historically trigger happy about discussing adding features
> in this group. This is not unique to D - all languages underwent the
> same process. But at this point it is a necessity that we start
> migrating our mindset from an endless wishlist - towards finding
> ingenious solutions within the language. Again, this is the case for
> every single language there is. Combining existing features towards new
> ends is in some ways more difficult than language design because you
> play within a confined ground, and I am a bit disappointed that a few
> posters have shown only contempt for such an effort.

The Herb Sutter interview that you recently posted a link to has an 
interesting point of view on that. One of the reasons that lambdas were added 
to C++0x was because Boost had shown how close you could get there using the 
language as it was and that it just wasn't good enough. Lambdas were added to 
the language precisely because they couldn't be done reasonably without 
additional language supported. On the other hand, other stuff that they added 
which Boost had tried to do - such as shared_ptr - were added as library 
solutions, because they worked as library solutions.

As you've said, we've reached the point that D is powerful enough and 
complicated enough that we should be first trying to see how well we can solve 
problems using the language itself rather than adding new features to it. As 
we do that, we should be able to see what is reasonably feasible within the 
language as it is and what just doesn't work. As we find things that just 
don't work but which we really want to be able to do, we can look at adding 
features to the language to deal with them, but we should definitely be 
looking at using the language as it is first.

In this particular case, while named arguments might arguably be nice, they're 
"nice to have," not a necessity. The question is how close we can get to 
having reasonable yes/no enums like we've been trying to do but without 
excessive boilerplate code. We may decide to add named arguments later, but D 
is really at the point that its current features need to be completely ironed 
out before we look at adding additional features that we don't really need.

I think that there _are_ features that we need to look at adding in some form 
or other (such as conditional attributes) in order to solve current problems 
in the language (such as the inability to use many attributes - such as pure 
and @safe - with templates without excessive duplication of code). But if a 
feature does not solve a pressing problem and/or can be reasonably solved by 
improving Phobos, then we should be improving Phobos.

- Jonathan M Davis