UFCS and constructors

[Timon Gehr]

On 07/02/2013 10:16 PM, Maxim Fomin wrote:
> On Tuesday, 2 July 2013 at 19:47:07 UTC, Timon Gehr wrote:
>>
>> Analogies are always broken, but the rest of the post reads to me
>> roughly like:
>>
>> "Dogs are not pets, and should not be treated as such.
>> They are fundamentally different from pets.
>>
>> Also, there are no other pets that bark, so it's incredibly bizarre as
>> well as inconsistent with the rest of the notion of a 'pet' to have a
>> pet dog.
>>
>> - Tmion M Gehr
>> "
>>
>
> class A
> {
>    this() {}
>    void foo(){}
> }
>
> A a = new A; // calls ctor, not foo
>
> Of course constructors are special because not any function is called
> upon object construction.

(We are discussing struct constructors.)

Of course. I fully agree. Obviously there is a reason why those 
functions are called constructors.

But one could now extend on the original argument, and say that eg. all 
the overloading rules should be different for constructors, because they 
are fundamentally different and should under no circumstances be treated 
like 'normal functions'. Do you see what the point is? This is not a 
valid way of justifying a breaking language change.

> Same logic

Logics that can prove some equivalent statements are not necessarily 
equivalent. (In particular, it does not rule out inconsistency of one of 
them.)

> was made when ability to overload
> some operators was blocked. All operators are, well, operators but you
> cannot overload all of them. It appears that sometimes it does make
> sense to restrict operation on some particular elements of the set and
> sometimes not.
> ...

Such restrictions need to be justified. The justification should make 
(at least some) sense. There is no point in heuristically designing 
language features from observations about other language features 
without applying insight.

(Anyway, I do not think that overloading of a fixed set of primitive 
operators using specially named member functions is a good mechanism for 
infix notation.)