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
