Simen Kjaeraas , dans le message (digitalmars.D:172349), a écrit :
On Thu, 12 Jul 2012 16:31:34 +0200, Christophe Travert
trav...@phare.normalesup.org wrote:
By the way, would it be possible to implement an opCmp that returns a
double, to allow it to return a NaN ? That may allow to create
On Thu, 12 Jul 2012 16:31:34 +0200, Christophe Travert
trav...@phare.normalesup.org wrote:
By the way, would it be possible to implement an opCmp that returns a
double, to allow it to return a NaN ? That may allow to create values
that are neither superior, nor inferior to other value, like
I posted this as an enhancement request over there:
http://d.puremagic.com/issues/show_bug.cgi?id=8381
Have you considered adding operator overloading using UFCS while
you're at it?
On 07/12/2012 12:05 PM, Thiez wrote:
Have you considered adding operator overloading using UFCS while you're
at it?
There is already an open issue about that iirc.
On Thursday, 12 July 2012 at 10:05:16 UTC, Thiez wrote:
Have you considered adding operator overloading using UFCS
while you're at it?
I assumed it's already possible to add operators non-intrusively,
because operators are just syntactic sugar for method calls:
++var; // actual
On Thursday, 12 July 2012 at 12:43:24 UTC, Tommi wrote:
On Thursday, 12 July 2012 at 10:05:16 UTC, Thiez wrote:
Have you considered adding operator overloading using UFCS
while you're at it?
I assumed it's already possible to add operators
non-intrusively, because operators are just
On Thursday, 12 July 2012 at 13:19:00 UTC, Thiez wrote:
It's already quite obvious that the compiler does not obey its
own rewrite rules (see
http://dlang.org/operatoroverloading.html#compare) Consider
opCmp:
a b
is rewritten to
a.opCmp(b) 0
or
b.opCmp(a) 0
Let's assume the first rule
Thiez , dans le message (digitalmars.D:172060), a écrit :
Have you considered adding operator overloading using UFCS
while you're at it?
I assumed it's already possible to add operators
non-intrusively, because operators are just syntactic sugar for
method calls:
++var; //
On Thursday, 12 July 2012 at 14:31:34 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
This behavior for opEquals is debatable, but make sense.
I don't think it's debatable at all. You must be able to figure
out how a class is going to behave just by looking at its
definition.
As I see it, the goal of uniform function call syntax, as
described here http://www.drdobbs.com/blogs/cpp/232700394, is to
allow non-intrusively extending the functionality of a type. I
think the current implementation comes short in accomplishing
this goal on two accounts:
1) You can't
On 2012-06-17 08:39, Tommi wrote:
As I see it, the goal of uniform function call syntax, as described here
http://www.drdobbs.com/blogs/cpp/232700394, is to allow non-intrusively
extending the functionality of a type. I think the current
implementation comes short in accomplishing this goal on
12 matches
Mail list logo
