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