UFCS for struct opCall?

[Timon Gehr]

On 04/10/2013 02:59 PM, Maxim Fomin wrote:
> On Tuesday, 9 April 2013 at 19:08:51 UTC, Timon Gehr wrote:
>> I am abstracting their essence. If you think there was any argument
>> that does not fit the above description, feel free to bring it up.
>
> a) UFCS and overloading are distinct topics. One does not enforce other
> to work in a particular way.

But this would support my view on the matter. I think this point has not 
been brought up in support of your view so far.

> For example, UFCS does not mean that
> a.typeid should be rewritten as typeid(a)

This is 100% a parser feature, there is no overloading involved.

> or foo!int can be written as int.foo.

No call syntax involved.

> Judging by enhancement requests in bugzilla, there is trend for
> asking anything like 'a..b..c'  to be writable as 'a.b...c' in general.
> None of such ideas is 100% right per se, including operator overloading.
>

This is not precise enough for me to get anything out of it.

> 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.

This is an argument which is similar to the general scheme I have 
sketched. The above is a somewhat elaborate claim that operator 
overloading is special

> It is possible to rewrite conflicting function name to
> other and use it, but it isn't possible to rewrite conflicting basic
> expression in terms of other basic expressions.

And it is not necessary. Why would it be?

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

I don't get that.

> The idea blows up and you have to use function call as currently.

You have to use function calls in any case, because overloaded operators 
are just function templates. Whether your operation is called "+" of "f" 
is a mere naming issue.

> By likely to be broken I mean higher
> probability to run in name conflict with operators than with regular
> methods

Name conflicts can be resolved in the usual fashion. Name conflicts 
occur only if both functions accept the same kind of input. There are 
not many ways to meaningfully overload operators for the same kind of 
data type. Furthermore, the same function name is not meaningful for 
every function. The "more likely" rests on the assumption that infix 
operator names are appropriate names for more functions than other 
function names. This is not justified.

> (and it would happen very likely because idea seems to be popular).
>

This therefore assumes that "many" will furiously start to name their 
functions in _inappropriate_ ways.
You have yet to provide a likely scenario.

> 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..."

I'd like to keep the discussion focused. We are discussing the general 
behaviour of rewriting, not specific rewrites. There is no question that 
D's treatment of non-alphanumeric function symbols is not the best possible.

> which does not necessarily means that this decision  is "incomplete" and "non sequitur".
>

This sentence does not make any sense.

> ...
>
> [...] I do not like when arguments are
> distorted or described as being absent, or people are portrayed as
> having no idea what they are talking about.
>

Me neither.

> Surely, I do understand advantages of the idea and understand why the
> idea is considered to be logical,

Do you also understand why special rules that restrict orthogonality of 
language features are harmful?

> I object not because being programming
> sadist, but because consider idea harmful and easy to abuse.

Most D features are easy to abuse. Deciding whether a feature is used in 
an abusive way is subjective at best and not generally decidable by an 
algorithm in any case.