UFCS for D

Steven Schveighoffer schveiguy at yahoo.com
Fri Mar 30 09:15:31 PDT 2012


On Fri, 30 Mar 2012 10:48:04 -0400, deadalnix <deadalnix at gmail.com> wrote:

> Le 30/03/2012 14:52, Steven Schveighoffer a écrit :
>> On Fri, 30 Mar 2012 08:22:12 -0400, deadalnix <deadalnix at gmail.com>  
>> wrote:
>>> Immagine you want to define your own to!xxx() for your type xxx. (It
>>> is dumb case because you have toString, but an interesting exercise
>>> because for your own stuff, not something that is specified in the
>>> language - like toString - the same could happen with no easy solution.
>>
>> I don't think this disproves anything. It should be possible without
>> ambiguity given the rules I stated.
>>
>> -Steve
>
> You are messing up everything.
>
> First, this have NOTHING to do with UFCS.

Yes it does.  The special rule only applies when using UFCS functions.

> Second, current D import system have no ambiguity. But you propose to  
> change that system. That would introduce ambiguity.

Stating it doesn't prove it.  I claim no ambiguity, simply because I  
cannot see what the ambiguous case would be.  It's very easy to disprove  
me, show one example.

> Even if you don't believe me, which is fine, it is safe to assume so  
> unless you can prove otherwise.

I'm not disputing the current module system is unambiguous.  I assert that  
my additions do not make it unambiguous.  Trying to prove that it's  
unambiguous would be really really hard, and require probably years of  
research.  I don't really want to prove it.

But disproving it can be done with one case.  If you believe it's  
ambiguous, you must have a case in mind, no?

-Steve


More information about the Digitalmars-d-announce mailing list