DMD 0.177 release [Length in slice expressions]

[Bill Baxter]

Chris Nicholson-Sauls wrote:
> 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.

In both of those cases the use seems rather silly to me because a and b 
are both single characters to begin with.  Might as well just type
   b[0 .. b.length];
   a[0 .. a.getIndexOf(';')];
instead.  But I get the point.  Sometimes you have
   g_openSocketHandles[0 .. g_openSocketHandles.getIndexOf()]

But maybe just allowing 'this' in the brackets is enough there, without 
going on and abbreviating it to $.  The $==.length proposal at least has 
the advantage of being backwards compatible.

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

Not sure I like $==this as must as $==.length.  I have pressing need for 
a brief syntax for specifying the length, but no such thing for a 
shorter form of 'this'.  But anyway, if you're going to allow '$' to 
mean 'this' inside brackets, first you first need the language feature 
that allows 'this' to be used inside brackets in the first place.  And 
maybe if you have that you'll find it's sufficient.

Another thing is if you're going to allow 'this' in brackets, then you 
should take the idea to its logical conclusions and allow it in member 
function call parameter lists too.  That might be nice for things like 
enum paramters.

Of course if $ gets translated into a call to a method/property, you 
could have it your way if you prefer for your classes.  Just use
     opDollar() { return this; }
and voila! You can use your $.getIndexOf(';').

--bb