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