DMD 0.177 release [Length in slice expressions]

[Chris Nicholson-Sauls]

Pragma wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>>
>> A simpler grammar would have been to simply allow:
>>
>> UnaryExpression:
>>     PostfixExpression
>>     & UnaryExpression
>>     ... etc. etc. ...
>>     $ PostfixExpression
>>
>> But this would have been ambiguous. If the compiler sees "$-1", then 
>> the bad grammar says that's a unary use of $ because -1 is a 
>> PostfixExpression. But that's not what we wanted! We wanted $ to be 
>> nullary. That's why I needed to put all the cases in UnaryExpression.
>>
> 
> Nice post, and one heck of an argument!
> 
> FWIW, I advocated something similar during the last round of debates 
> before the '$' operator was introduced.  What I wanted to see was '$' to 
> become like 'this' within slice and array expressions, so that the 
> issues regarding 'length' could be resolved.  In essence one could 
> simply say '$.length' and mean 'the length of the current array':
> 
> b[0 .. $.length];
> a[0 .. $.getIndexOf(';')];
> 
> So in essence, every use of '$' would be a 'nullary' operator - an alias 
> if you will.
> 

I rather like this.  And I think I liked it then, too... if not, oh well.

> I'd imagine that extending things in this manner would simplify things 
> grammatically while allowing for a wider category of uses.  However, it 
> doesn't solve the issue that you brought up, and that I've quoted above.
> 
> c[$-1];
> 
> It looks like it should be an implicit cast of the '$' to a size_t 
> (length), via it's use in an expression.  Any thoughts on this?

If $ is like a 'this', then it ought to be have semantically the same, so if $ is a 
class/struct with an opCast to size_t defined, the obvious happens.  If its anything else, 
it ought to be a compile time error,  perhaps suggesting you had meant '$.length' instead.

-- Chris Nicholson-Sauls