[Issue 9786] Allow [non-member|UFCS] implementation of operators

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9786


Maxim Fomin <maxim at maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim at maxim-fomin.ru


--- Comment #5 from Maxim Fomin <maxim at maxim-fomin.ru> 2013-03-23 02:59:44 PDT ---
Operator overloaded methods are special functions. There are several problems
with UFCSising them.

1) When there is conflict between different functions across several modules,
it is easy to overcome the problem by renaming functions. If you have two
opCalls for structs (for example) in two different modules and if you try to
use them simultaneously, any code like S() is broken and have to be rewritten.
Worse may happen with opBinary like in 
   S a, b;
   .. 
   a = a + b;
Now opBinary is hijacked by something else and code is fundametally broken.
Rewriting a+b is not the same as rewriting a.foo(). And in presence of regular
function name conflict it is possible to rename for ex. foo() to myFoo() and be
happy, but it is not posssible to have a +myOpBin b, so overloading operator
immediatly loses its sense.

2) Druntime may dependend on operator overloading functions. When you try to
UFCSizly overload operator, and get return value from function which was
compiled when operator was not overloaded (due to separate compilation model),
you may have logically incorrect value: you expect that operation was performed
with overloaded operators but actually it was not the case.

In general, I prefer to leave overloading decision to owner of the type.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------