Who favors the current D1 situation?

[Kris]

"Walter Bright" <newshound1 at digitalmars.com> wrote
> Kris wrote:
>> While I understand how things can sometimes quickly become complex while 
>> trying to support a simple notion, there's nothing trivial at all about 
>> using or comprehending the D2 const mechanisms. A claim has been made 
>> that one does not have to use or be aware of const or invariant to use D2 
>> ... unfortunately that does not appear to be the case in practice, and 
>> the added complexity makes D2 harder to work with than D1.
>
> In some ways it is more complex, but in other ways it is simpler. Not the 
> language, but the way it is used. For instance, you shouldn't have to be 
> worrying about defensively duping invariant arrays.

It is simpler and generally more effective to design an API which avoids the 
.dup issue. Thus, IMO, const and invariant typically have little value for 
well over 90% of engineering with D, assuming 'in' remains as always. Yeah, 
I'm aware of and appreciate the potential benefits involved, both large and 
small and in their various guises for current and future goodies within D 
... but the usage is currently not sufficiently transparent.

Usage of dup (and idup) is not a good poster-child to hold aloft, when they 
can be avoided in the vast majority of cases. For example, in all of Tango 
there's only one instance where a const return would be nice to have, due 
mostly to an avoidance of the situation. The usage of  D1 'in' can suffice 
for all read-only parameters. Tango is a large body of code, as you know, 
with attention given to efficiency. One might hope the highly narrow scope 
therein for D2 const/invariant might indicate something of value for you --  
perhaps that const/invariant might slip into a "special consideration" usage 
instead? If it simplified the syntax and/or usage, a lot of people would be 
jumping into D2 instead of remaining with D1

What I'm saying is effectively this: you don't have to solve all the const 
cases to still have a stupidly-effective language. The tradeoffs to get 
there so far are, imo, too costly in areas of comprehension and usability - 
two huge factors in the attraction of D in the first place. Some folks might 
disagree, and that's cool.

It would be interesting to draw a graph plotting "degree of involvement in 
large-scale D engineering" versus "perceived complexity/value tradeoff 
regarding const"

2c