UFCS for struct opCall?

[Simen Kjaeraas]

On 2013-04-10, 14:59, Maxim Fomin wrote:

> a) UFCS and overloading are distinct topics. One does not enforce other  
> to work in a particular way.

Exactly. So if a + b may be rewritten a.opBinary(b), and a.foo(b) may be
rewritten foo(a, b), it makes sense that a + b may be rewritten
opBinary(a, b). Otherwise, UFCS forces operator overloading to work in a
particular way (an/or the other way around).


> For example, UFCS does not mean that a.typeid should be rewritten as  
> typeid(a) or foo!int can be written as int.foo.

The reason UFCS does not work for the first is special casing in the
parser.

The reason it does not work for the second is it's not a function call
at all (or, possibly, a parameter-less one).


> b) UFCSing operator overloading is a feature which can be easily and  
> likely to broken. By easily broken I mean that despite the idea looks  
> 'cool', its advantages evaporate when there are multiple opBinaries and  
> other stuff.
[snip]
> (and it would happen very likely because idea seems to be popular).

That a feature is popular is rarely a good argument for removing it.
The exact same argument has been used against operator overloading in
the past, and apart from C++'s streams, I've never heard of anyone
who's actually abused the feature, only these hypothetical scenarios
where someone overload + to mean 'connect to database/launch missiles'.
It's not a good argument. People will not start searching for ways to
abuse a feature just because it's there, and accidental problems are
likely to be rare and easily circumvented.

Would you believe the exact same argument was used against regular
function overloading back in the day?


> There is no possibility for S[my.bar.mod.opCall]().

I have no idea what you're even trying to communicate, much less prove,
with this construct. Complexity is complex? People will write ugly code
no matter? I guess the first part is a static opIndex, and it basically
behaves like an AA with function keys and values? What are you even
trying to do?


> By the way, not all operators can be overloaded because "... These  
> operators [comma, ternary, && and || ] were considered to create more  
> confusion than flexibility if ever overloaded..." which does not  
> necessarily means that this decision is "incomplete" and "non sequitur".

Of course not. Fairly reasonable arguments are even presented right there.
I am still somewhat more in favor of letting the programmer have that
flexibility, and berate and/or fire him/her if it ever gets used.

I have occasionally wanted to overload && and ||, though in those cases
| and & have been good enough. I'd love to have a few more operators,
though. × comes immediately to mind, and ⋅, ∩, ∪, ⊂, and ⊃ quickly
follow.

-- 
Simen