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-therefore-thats-how-it-
-must-work arguments, that often appear here, do not really
help.
I am against proposal not because dmd doesn't do it but because I
believe it is unwisely pushed in a manner that defects the
purpose of proposal. BTW, some operators are not overloadable
because, if I remember right, "they were considered to create
more confusion than flexibility if ever overloaded". Leaving UFCS
with operator overloading as they are now does make sense,
because of similar reason.
Well, i don't think anybody wants to /override/ existing
operators - it's only about
allowing /extending/ the functionality of non-local types, by
adding support for additional
ops and/or types. While being able to override existing methods
with UFCS would have some
uses, allowing that would also introduce additional problems.
Anyway, if you need to modify how a type's existing ops work
you can always sub-type -
this is also true in the (non-virtual) method case; UFCS is
basically just syntax sugar
(which allows you to transparently locally inject methods w/o
creating a new type,
downcasting and handling the (implicit) upcasts (which could be
problematic when eg
working with (pointers-to-)structs)).
artur
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 overloading methods but as soon as you import some
other modules, authors of which also consider UFCS operators a
good idea, everything breaks including namespace conflict as well
as loosing ability to manipulate that type within built-in
expression as well.
