DMD 0.177 release [Length in slice expressions]

[Dave]

Andrei Alexandrescu (See Website For Email) wrote:
> 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.
> 

Are you suggesting either / both:

slice = array[x .. array.length];
slice2 = array2[y .. #];

?

Since length and $ are pretty easily grep-able in the context of slice syntax, perhaps it's not a 
"huge" issue if these were deprecated now and then not supported in the span of a couple of 1.0.x 
releases or so (instead of a year)?

>> 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.
> 

Since one of the main drivers for 1.0 by Jan. 1, 2007 is to encourage / solidify library 
development, and since library design could be affected in a large way by this issue, I'd say it's 
best to figure this out before releasing 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.
> 

If indeed it will be an embarrassment, better to take care of this sooner (pre-1.0) rather than 
later, IMHO.

Thanks,

- Dave