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 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.
Members do not cause conflicts with free functions.
Alias this takes precedence as it is a member of the type.
What is the issue?
