DMD 0.177 release [Length in slice expressions]

Chris Nicholson-Sauls ibisbasenji at gmail.com
Thu Dec 21 22:36:44 PST 2006


Bill Baxter wrote:
> 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.

The problem with actually using the 'this' keyword in place of $ is one of ambiguity. 
Given a collection class 'Set' and some other class 'Foo', what to do if a 'this' is used 
within a slice of a 'Set' instance within a member of 'Foo'?  Does it evaluate to the Foo 
referance it would in all other cases?  Or to a Set referanc?  And if the latter, how to 
get the Foo referance if that really is what I wanted?

The $ would have to be different from 'this' in the classes' sense.  Perhaps it would be 
better to call it a 'self' or even a 'with' than a 'this'.

-- Chris Nicholson-Sauls



More information about the Digitalmars-d-announce mailing list