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
