Flag proposal

[Andrei Alexandrescu]

On 6/10/11 7:04 PM, bearophile wrote:
> Andrei:
>
>> Design decisions are always taken in a context,
>
> Right. But wasn't your comment about Scala named arguments complexity
> too out of context?

What I did was to say that Don's and others' point, corroborated with 
the fact that Scala found it necessary to add that feature to the 
language, suggests that we need to worry about that.

>> 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.
>
> There are few basic features that are missing that are better as
> built-ins, even now. Tuple unpacking syntax sugar, named arguments,
> computed gotos, and few other smaller things. Do you want to freeze D
> language to D2 and not take a look at ideas for D3?

Falling for either extreme would be a mistake.

>> and I am a bit disappointed that a few posters have shown only
>> contempt for such an effort.
>
> You need to take a better look at the kind of people that are in this
> forum. People here are walking away from C++, Java (and even Python),
> looking for a feature-rich language that avoids some of the syntax
> kludges their former languages force them to use in their programs.

I'd love to see more evidence to this claim.

> So it's not so strange that people in this forum have on average a
> significantly lower tolerance to tricks like your Flag proposal. In a
> C++ forum your Flag idea probably is much more welcome, because
> compared to D programmers probably C++ programmers accept a higher
> level of noise and ugliness in their code :-)

I don't think that's the reason. You should have seen the C++ forums up 
until about 1997. They were brimming with enthusiastic proposals for 
language changes. Interesting work became possible after it became clear 
to everyone that the language is now given, so it's time to use what's 
there. D, too, is receiving an increasing amount of real work from the 
community since TDPL's publication.

>> What's wrong with myTuple.expand?
>
> It does nothing of what I need? Haven't we had this discussion
> already? I am having a huge deja-vu :-) I have discussed this topic
> several times already. Didn't you agree about the need of unpacking
> syntax sugar for tuples? I am confused
> now..................................

I must be the one confused, but at best we shouldn't spread ourselves 
too thin.


Andrei