DMD 0.177 release [Length in slice expressions]

[Andrei Alexandrescu (See Website For Email)]

Don Clugston wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Similarly, let's say that a group of revolutionaries convinces Walter 
>> (as I understand happened in case of using "length" and "$" inside 
>> slice expressions, which is a shame and an absolute disaster that must 
>> be undone at all costs) to implement "auto"
> 
> This off-hand remark worries me. I presume that you mean being able to 
> reference the length of a string, from inside the slice? (rather than 
> simply the notation).
> And the problem being that it requires a sliceable entity to know its 
> length? Or is the problem more serious than that?
> It's worrying because any change would break an enormous amount of code.

It would indeed break an enormous amount of code, but "all costs" 
includes "enormous costs". :o) A reasonable migration path is to 
deprecate them soon and make them illegal over the course of one year.

A small book could be written on just how bad language design is using 
"length" and "$" to capture slice size inside a slice expression. I 
managed to write two lengthy emails to Walter about them, and just 
barely got started. Long story short, "length" introduces a keyword 
through the back door, effectively making any use of "length" anywhere 
unrecommended and highly fragile. Using "$" is a waste of symbolic real 
estate to serve a narrow purpose; the semantics isn't naturally 
generalized to its logical conclusion; and the choice of symbol itself 
as a reminiscent of Perl's regexp is at best dubious ("#" would have 
been vastly better as it has count connotation in natural language, and 
making it into an operator would have fixed the generalization issue). 
As things stand now, the rules governing the popping up of "length" and 
"$" constitute a sudden boo-boo on an otherwise carefully designed 
expression landscape.

> These issues you're raising seem to be far too fundamental to be fixed 
> in the next few days, casting grave doubts on whether a D1.0 release on 
> Jan 1 is a good idea.

The lvalue/rvalue issue is fundamental. I'm not in the position to 
assess whether it's a maker or breaker of D 1.0.

The "length"/"$" issue is not fundamental the same way that C's 
declaration syntax, Java's throw specifications, C++'s use of "<" and 
">" for templates, and Mao Zedong's refusal to use a toothbrush are not 
fundamental. It will "just" go down in history as a huge embarrassment 
and a good resource for cheap shooters and naysayers. If I understand 
its genesis, it will also be a canonical example of why design by 
committee is bad.


Andrei