Operator overloading through UFCS doesn't work
Maxim Fomin
maxim at maxim-fomin.ru
Tue Oct 16 08:57:54 PDT 2012
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.
More information about the Digitalmars-d-learn
mailing list