Operator overloading through UFCS doesn't work

Artur Skawina art.08.09 at gmail.com
Wed Oct 17 13:38:06 PDT 2012


On 10/17/12 12:46, Timon Gehr wrote:
> On 10/15/2012 01:00 PM, Artur Skawina wrote:
>> ...
>>
>> An overloaded operator is just another normal method; you get the same type of
>> problems when dealing with "normal" methods - eg in types having an "alias this" -
>>   an UFCS "method" must take precedence over one reachable via the alias - just like
>> in the overloaded op case. The only sane alternative would be disallowing UFCS
>> for types with an "alias this" (which would be a severe limitation).
>> ...
> 
> Just no. Why make symbol lookup even more complicated just in order to
> add an strange exception to the language that either enables new forms
> of hijacking or would be a severe limitation?

Like i said in a later message - I think the /functionality/ should be available,
how it's handled is a different issue. The reason why I'd want UFCS take priority
over alias-this is that in the presence of multiple aliases and external components
method hijacking is actually likely to become a problem. Eg a newer /library/ version
can silently hijack an apps UFCS extension "method". Plus, the aliases can severely
limit the available ufcs namespace; and the compiler won't even flag many conflicts
as errors.

UFCS is a much cheaper alternative to sub-typing, having it work for as many cases
as possible is important. Think: app that uses an own GUI module on top of a themeing
library on top of a GUI widget toolkit on top of a basic windowing system. Being able
to extend functionality (by adding just a method or two, in the app) without having to
create an extra type hierarchy and dealing with all the conversion issues could be very
useful.

UFCS is just optional syntax sugar, so I can buy the 'no changes for this' argument -
only then I fear that it's usefulness decreases to the point where the cost is no
longer justified. For the cases where creating a new type is overkill, one can always
use a free function.

[Yeah, I'm ignoring the 'functional-style' aspect, I know. UFCS might help there,
 but a DSL would be better long-term solution IMHO, and would also avoid the
 @property related issues (extra parens). But that's off-topic, at least in this thread.]

artur


More information about the Digitalmars-d-learn mailing list