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 method
opUnary of the thing referred to by that alias this.
http://dpaste.dzfl.pl/d0a4431d
Free function doesn't suit better than actual method. The
issue is
absence of the actual method.
opUnary method has priority over alias this, which does make
sense
because alias this is chosen only when it is impossible to
apply
operation over A type. If this request is approved and
compiler has
opUnary definition outside type (which suits better then alias
this)
such function would hijack alias this. If not, there is a new
case when
something is going special than at usual cases and only for
the purpose
of writing operator overloading methods outside the body of
the type.
The goal must be to get rid of all special behaviour that can
result in
strange interactions.
Add the suitable operator function templates to built-in types.
Always
rewrite operators to operator function calls. Problem solved.
...
You have a struct with alias this to int without overloaded
operators. It (say, struct.d) contains code with structure
increments. Some other module (say bob.d), which import the
structure, defines function supposed to overload opUnary. If
operators are always rewritten to function calls, now function
should be called in module bob.d, as well as in struct.d if they
are compiled together. It certainly not what author of struct.d
expected. The case can be even more interesting, if alias this in
struct.d were absent at a time when bob.d was written and at some
point of future Bob is updating his sources.
