DMD 0.177 release [Length in slice expressions]

[Derek Parnell]

On Wed, 20 Dec 2006 06:24:28 -0800, Andrei Alexandrescu (See Website For
Email) wrote:

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

Please share your thoughts here if you can too.

> Long story short, "length" introduces a keyword 
> through the back door, effectively making any use of "length" anywhere 
> unrecommended and highly fragile. 

There is no arguement from me on that score.

> Using "$" is a waste of symbolic real 
> estate to serve a narrow purpose;

By that do you mean that the symbol "$" could be better utilized elsewhere
in the language?

> the semantics isn't naturally generalized to its logical conclusion;

I have no idea what that statement means. The semantics of *what*? Define
"naturally generalized" in absolute terms without recourse to opinion. What
is the "logical conclusion" you talk of?

> 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

The concept was to have a very short symbol to represent the array's
current element count. A number of different symbols were put forward, "#"
being one of them. Walter rejected that one because it was already used for
something else - the 'special token sequences' construct, such as "#line".
Also symbols that consisted of identifier characters all have the same
problem as "length" does. I favoured "$" because it was a single-character
symbol and is already used in similar concepts inside regular expression
syntaxes.

Although the exact symbol that is 'finally' decided upon is not a burning
issue for me, there would have to be a very solid argument for the provable
superiority of that one symbol over the rest. And currently, the choice
between "$" and "#" is equivalent in my mind.

> and making it into an operator would have fixed the generalization issue

Would this lead to an opLength() method available for overloading?

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

Still sounds like an opinion and not a fact, in my opinion ;-)

-- 
Derek