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? M
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 to
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 forced
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 confli
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 built
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 con
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 limi
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 ov
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 previo
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 Gehr
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 conside
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 di
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/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 ta
On 10/17/2012 01:51 PM, Maxim Fomin wrote:
On Wednesday, 17 October 2012 at 11:11:26 UTC, Timon Gehr wrote:
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 opUna
On 10/17/2012 01:32 PM, Maxim Fomin wrote:
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 you
On Wednesday, 17 October 2012 at 11:11:26 UTC, Timon Gehr wrote:
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
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
... and
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
me
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 i
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.
http
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 wha
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 one reachable via the alias - just
lik
On 10/16/12 17:57, Maxim Fomin wrote:
> This doesn't scale well. Certanly, nobody would intentionally create
> problems. But if you import code of other people, whom you cannot control,
> override problems occurs.
>
> At NG discussion it may look nice to define some type and then add operator
>
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 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 wer
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
some-compiler-happens-to-implement-it-like-that-today-theref
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 s
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 any
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) con
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 canno
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 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 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 u
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 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 treati
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 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 som
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 pro
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 f
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
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 make
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
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 und
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:
var.opUnary!"
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 f
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 "fur
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 U
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
problem
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
works,
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 wit
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: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 rewr
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.
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
57 matches
Mail list logo