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