sorting hidden data.

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Oct 4 09:10:01 PDT 2010


On 10/4/10 6:29 CDT, Steven Schveighoffer wrote:
> On Wed, 29 Sep 2010 16:37:34 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 9/29/10 13:10 PDT, Jacob Carlborg wrote:
>>> Would that be the uniform function call syntax that I've been waiting
>>> for since I first heard of it?
>>
>> Yah. One unpleasant issue I found with it (as it's already implemented
>> for arrays) is a chicken-and-egg thing: say I want to provide
>> operation moveFront only if the type doesn't define it yet. Without
>> UCF (Uniform Call Syntax) things are simple:
>>
>> auto moveFront(R)(ref R r)
>> if (!is(typeof(r.moveFront())) && !hasElaborateCopy!(ElementType!R)) {
>> return r.front;
>> }
>>
>> With UCF things get messy because introducing moveFront at global
>> level does make r.moveFront() legit, so the if clause returns true,
>> which is weird because the function shouldn't have been introduced
>> yet. So the compiler gets confused by this lying Cretan riddle - it
>> recurses forever (when R is an array).
>>
>> The solution would be probably to not consider the symbol introduced
>> until the if-clause has cleared.
>
> __traits(hasMember, r, "moveFront") && rest_of_expression_you_had
>
> -Steve

Yah, I know - in fact I added a trait hasMember(T, "name") to std.traits 
that hides the __traits. For some reason that still has issues, probably 
due to lack of short-circuit evaluation of && during compilation (but 
I'm not positive).

Things are still unpleasant even assuming that works, so I think we need 
to look into that when considering committing to uniform call syntax.


Andrei


More information about the Digitalmars-d mailing list