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.
