On Tuesday, May 31, 2016 14:11:58 ixid via Digitalmars-d-learn wrote:
> On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote:
> > And the fact that allowing free functions to overload operators
> > via UFCS sends us into that territory just highlights the fact
> > that they're a horrible
On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote:
And the fact that allowing free functions to overload operators
via UFCS sends us into that territory just highlights the fact
that they're a horrible idea.
- Jonathan M Davis
Do you have any examples of UFCS doing bad things?
Here's one more vote for extending UFCS to operator overloading.
Elie wrote that it's "a restriction that seems pointless and
arbitrary"... which summarizes my own thoughts rather well, too.
There are certainly concerning scenarios that can arise from
making this change, but the correct way
On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote:
On Friday, May 27, 2016 09:08:20 Marc Schütz via
Digitalmars-d-learn wrote:
On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis
wrote:
> The difference is that it's impossible to do
> 10.opBinary!"+"(15), so if you're
On Friday, May 27, 2016 09:08:20 Marc Schütz via Digitalmars-d-learn wrote:
> On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote:
> > The difference is that it's impossible to do
> > 10.opBinary!"+"(15), so if you're forced to do
> > foo.opBinary!"+"(bar) to get around a symbol
On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote:
The difference is that it's impossible to do
10.opBinary!"+"(15), so if you're forced to do
foo.opBinary!"+"(bar) to get around a symbol conflict, it won't
work with built-in types.
Well, that begs the question: Why don't
On 25.05.2016 01:19, Elie Morisse wrote:
On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
Afaik free-function operator overloads (but not in the context of
UFCS) were considered and turned down because D did not want to get
amidst discussions about adding Koenig lookup. UFCS does
On Thursday, May 26, 2016 16:24:37 Elie Morisse via Digitalmars-d-learn wrote:
> On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote:
> > The difference is that it's impossible to do
> > 10.opBinary!"+"(15), so if you're forced to do
> > foo.opBinary!"+"(bar) to get around a symbol
On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote:
The difference is that it's impossible to do
10.opBinary!"+"(15), so if you're forced to do
foo.opBinary!"+"(bar) to get around a symbol conflict, it won't
work with built-in types.
Obviously operator overloading should be
On Wednesday, May 25, 2016 23:31:18 Elie Morisse via Digitalmars-d-learn
wrote:
> On Wednesday, 25 May 2016 at 21:50:06 UTC, Jonathan M Davis wrote:
> > It's not an overloaded operator anymore at that point, and that
> > definitely fails to work for generic code, since not all
> > operators are
On Wednesday, 25 May 2016 at 21:50:06 UTC, Jonathan M Davis wrote:
It's not an overloaded operator anymore at that point, and that
definitely fails to work for generic code, since not all
operators are overloaded operators. Free functions don't have
that problem.
Sorry to reiterate the
On Wednesday, May 25, 2016 15:46:23 Elie Morisse via Digitalmars-d-learn
wrote:
> On Tuesday, 24 May 2016 at 23:43:46 UTC, Jonathan M Davis wrote:
> > On Tuesday, May 24, 2016 23:19:32 Elie Morisse via
> >
> > Digitalmars-d-learn wrote:
> >> On Saturday, 13 October 2012 at 22:58:56 UTC, Timon
On Tuesday, 24 May 2016 at 23:43:46 UTC, Jonathan M Davis wrote:
On Tuesday, May 24, 2016 23:19:32 Elie Morisse via
Digitalmars-d-learn wrote:
On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
> Afaik free-function operator overloads (but not in the
> context of UFCS) were
On Tuesday, May 24, 2016 23:19:32 Elie Morisse via Digitalmars-d-learn wrote:
> On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
> > Afaik free-function operator overloads (but not in the context
> > of UFCS) were considered and turned down because D did not want
> > to get amidst
On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote:
Afaik free-function operator overloads (but not in the context
of UFCS) were considered and turned down because D did not want
to get amidst discussions about adding Koenig lookup. UFCS does
not do Koenig lookup.
I don't get it,
On 10/16/2012 05:57 PM, Maxim Fomin wrote:
...
At NG discussion it may look nice to define some type and then add
operator overloading methods
Operator overloading is not magic, so your statement can be shortened to
... and then add methods
Which is still not correct, because that is not
On 10/14/2012 09:14 AM, Maxim Fomin wrote:
On Sunday, 14 October 2012 at 07:01:30 UTC, Tommi wrote:
Actually, it seems that alias this has precedence over UFCS. So, a
free function opUnary wouldn't ever suit better than an actual method
opUnary of the thing referred to by that alias this.
On Wednesday, 17 October 2012 at 10:24:57 UTC, Artur Skawina
wrote:
Operator overloading can be abused - that's an obvious and well
known fact. But that
same feature can also be very useful, if used right. Worrying
about UFCS problems in
the context of op-overloading needlessly complicates the
On 10/14/2012 09:01 AM, Maxim Fomin wrote:
On Saturday, 13 October 2012 at 19:50:02 UTC, Timon Gehr wrote:
On 10/13/2012 06:02 PM, Maxim Fomin wrote:
...
Different groups of people have different mind and same things produce
different sense on them. From my point of view operator overloading
On Wednesday, 17 October 2012 at 11:00:05 UTC, Timon Gehr wrote:
On 10/16/2012 05:57 PM, Maxim Fomin wrote:
...
At NG discussion it may look nice to define some type and then
add
operator overloading methods
Operator overloading is not magic, so your statement can be
shortened to
...
On 10/17/12 12:46, Timon Gehr wrote:
On 10/15/2012 01:00 PM, Artur Skawina wrote:
...
An overloaded operator is just another normal method; you get the same type
of
problems when dealing with normal methods - eg in types having an alias
this -
an UFCS method must take precedence over
On Tuesday, 16 October 2012 at 00:50:54 UTC, Artur Skawina wrote:
Actually, I'm not really in any camp. UFCS has several obvious
problems plus likely
quite a few more subtle ones. Ignoring the issues does not make
them go away and
the
On Monday, 15 October 2012 at 09:33:23 UTC, Maxim Fomin wrote:
---foo.d---
struct A
{
int i;
alias i this;
}
---bar.d---
int opUnary(string T)(A a) { ... }
...
{
++a;
}
---
I. i is incremented, opUnary is not called. However opUnary
matches better to the actual type and if it
On Tuesday, 16 October 2012 at 16:10:31 UTC, Tommi wrote:
On Monday, 15 October 2012 at 09:33:23 UTC, Maxim Fomin wrote:
---foo.d---
struct A
{
int i;
alias i this;
}
---bar.d---
int opUnary(string T)(A a) { ... }
...
{
++a;
}
---
I. i is incremented, opUnary is not called. However
On Sunday, 14 October 2012 at 19:50:54 UTC, Artur Skawina wrote:
On 10/14/12 08:13, Maxim Fomin wrote:
The only mentioned reason is to allow writing operator
overloading methods outside type scope - just because somebody
(currently two people) consider it logical to broaden UFCS
usage.
It's
On Sunday, 14 October 2012 at 20:15:15 UTC, Tommi wrote:
On Sunday, 14 October 2012 at 07:14:25 UTC, Maxim Fomin wrote:
If this request is approved and compiler has opUnary
definition outside type (which suits better then alias
this) such function would hijack alias this.
Free functions
On 10/15/12 10:17, Maxim Fomin wrote:
On Sunday, 14 October 2012 at 19:50:54 UTC, Artur Skawina wrote:
On 10/14/12 08:13, Maxim Fomin wrote:
The only mentioned reason is to allow writing operator overloading methods
outside type scope - just because somebody (currently two people) consider
On Monday, 15 October 2012 at 11:01:13 UTC, Artur Skawina wrote:
UFCS has pros and cons. I could agree that it has problems and
should be removed
from the language completely. But if the feature is there, it
should work, w/o any
unnecessary special cases.
Special cases would be created by
On 10/15/12 17:49, Maxim Fomin wrote:
On Monday, 15 October 2012 at 11:01:13 UTC, Artur Skawina wrote:
UFCS has pros and cons. I could agree that it has problems and should be
removed
from the language completely. But if the feature is there, it should work,
w/o any
unnecessary special
On Saturday, 13 October 2012 at 22:34:19 UTC, H. S. Teoh wrote:
OK, before this thread devolves into a shouting match, I'd like
to
understand what was the rationale behind this restriction. What
were the
reasons behind not allowing a non-member function to overload an
operator? What are the
On Saturday, 13 October 2012 at 17:01:27 UTC, Tommi wrote:
Another way to describe my reasoning...
According to TDPL, if var is a variable of a user-defined type,
then:
++var
gets rewritten as:
var.opUnary!++()
Not always. If user-defined type has an alias this to integer
member, than
On Sunday, 14 October 2012 at 06:22:03 UTC, Maxim Fomin wrote:
On Saturday, 13 October 2012 at 17:01:27 UTC, Tommi wrote:
Another way to describe my reasoning...
According to TDPL, if var is a variable of a user-defined
type, then:
++var
gets rewritten as:
var.opUnary!++()
Not always. If
On Saturday, 13 October 2012 at 19:50:02 UTC, Timon Gehr wrote:
On 10/13/2012 06:02 PM, Maxim Fomin wrote:
...
Different groups of people have different mind and same things
produce
different sense on them. From my point of view operator
overloading
methods are special functions and not
On Sunday, 14 October 2012 at 07:01:30 UTC, Tommi wrote:
Actually, it seems that alias this has precedence over UFCS.
So, a free function opUnary wouldn't ever suit better than an
actual method opUnary of the thing referred to by that alias
this.
http://dpaste.dzfl.pl/d0a4431d
Free function
On 10/14/12 08:13, Maxim Fomin wrote:
The only mentioned reason is to allow writing operator overloading methods
outside type scope - just because somebody (currently two people) consider it
logical to broaden UFCS usage.
It's more than two people... Also, it's not about broadening UFCS
On Sunday, 14 October 2012 at 07:14:25 UTC, Maxim Fomin wrote:
If this request is approved and compiler has opUnary definition
outside type (which suits better then alias
this) such function would hijack alias this.
Free functions cannot and must not ever hijack, i.e. modify
existing
Quote from TDPL: D’s approach to operator overloading is
simple: whenever at least one participant in an operator
expression is of user-defined type, the compiler rewrites the
expression into a regular method call with a specific name. Then
the regular language rules apply.
According to the
On Saturday, 13 October 2012 at 08:36:19 UTC, Tommi wrote:
Quote from TDPL: D’s approach to operator overloading is
simple: whenever at least one participant in an operator
expression is of user-defined type, the compiler rewrites the
expression into a regular method call with a specific name.
On Saturday, October 13, 2012 11:06:27 Jakob Ovrum wrote:
On Saturday, 13 October 2012 at 08:36:19 UTC, Tommi wrote:
Quote from TDPL: D’s approach to operator overloading is
simple: whenever at least one participant in an operator
expression is of user-defined type, the compiler rewrites
On Saturday, 13 October 2012 at 09:06:28 UTC, Jakob Ovrum wrote:
Do note that this says *method* call. Your example doesn't use
methods. Hence, the current state of operator overloading is
consistent with TDPL.
I don't agree with the last sentence. According to TDPL:
1) whenever at least one
On Saturday, October 13, 2012 11:41:07 Tommi wrote:
On Saturday, 13 October 2012 at 09:06:28 UTC, Jakob Ovrum wrote:
Do note that this says *method* call. Your example doesn't use
methods. Hence, the current state of operator overloading is
consistent with TDPL.
I don't agree with the
On Saturday, 13 October 2012 at 09:50:05 UTC, Jonathan M Davis
wrote:
It is most definitely _by design_ that you cannot
overload operators except as member functions.
I don't understand this design choice then. I don't see any
problem in allowing UFCS operators. Because of the way UFCS
On Saturday, 13 October 2012 at 10:00:22 UTC, Tommi wrote:
On Saturday, 13 October 2012 at 09:50:05 UTC, Jonathan M Davis
wrote:
It is most definitely _by design_ that you cannot
overload operators except as member functions.
I don't understand this design choice then. I don't see any
On Saturday, 13 October 2012 at 11:50:40 UTC, Maxim Fomin wrote:
I think implementing UFCS operator overloading is problematic.
Firstly, you want to put this language addition too far.
I don't see this as taking UFCS functionality further. Rather,
I think it's simply more logical that with
On Saturday, 13 October 2012 at 15:06:14 UTC, Tommi wrote:
On Saturday, 13 October 2012 at 11:50:40 UTC, Maxim Fomin wrote:
I think implementing UFCS operator overloading is problematic.
Firstly, you want to put this language addition too far.
I don't see this as taking UFCS functionality
On Saturday, 13 October 2012 at 16:02:25 UTC, Maxim Fomin wrote:
From my point of view operator overloading methods are
special functions and not treating them as candidates for
UFCS does make more sense.
I can think of only one thing that makes custom operator methods
special or different
Another way to describe my reasoning...
According to TDPL, if var is a variable of a user-defined type,
then:
++var
gets rewritten as:
var.opUnary!++()
Thus, it would be very logical to assume that it doesn't matter
whether you write:
++var
...or, write the following instead:
On 10/13/2012 06:02 PM, Maxim Fomin wrote:
...
Different groups of people have different mind and same things produce
different sense on them. From my point of view operator overloading
methods are special functions and not treating them as candidates for
UFCS does make more sense.
I do not
On Saturday, October 13, 2012 19:01:26 Tommi wrote:
Another way to describe my reasoning...
According to TDPL, if var is a variable of a user-defined type,
then:
++var
gets rewritten as:
var.opUnary!++()
Thus, it would be very logical to assume that it doesn't matter
whether you write:
On 10/13/2012 10:15 PM, Jonathan M Davis wrote:
...
construct is using syntactic sugar such as UFCS, because _all_ of that
syntactic sugar must be lowered to code which _isn't_ syntactic sugar anymore.
That is not what lowering means.
It would be far more expensive to have to continually
On Sun, Oct 14, 2012 at 12:12:01AM +0200, Timon Gehr wrote:
On 10/13/2012 10:15 PM, Jonathan M Davis wrote:
[...]
but they _aren't_ mixed and they will _never_ be mixed. If it had
_ever_ been intended that it be possible to overload operators as
free functions, then we'd simply have made it so
On 10/14/2012 12:36 AM, H. S. Teoh wrote:
On Sun, Oct 14, 2012 at 12:12:01AM +0200, Timon Gehr wrote:
On 10/13/2012 10:15 PM, Jonathan M Davis wrote:
[...]
but they _aren't_ mixed and they will _never_ be mixed. If it had
_ever_ been intended that it be possible to overload operators as
free
52 matches
Mail list logo
