As I see it, the goal of uniform function call syntax, as described here http://www.drdobbs.com/blogs/cpp/232700394, is to allow non-intrusively extending the functionality of a type. I think the current implementation comes short in accomplishing this goal on two accounts:

1) You can't non-intrusively add static member functions
2) You can't non-intrusively add constructors

So, I'm suggesting these two features to be added to the language:

1. Static method lowering rules
    If function calls like the following are encountered...
    A) Type.compute(<ARGUMENTS>);
    B) Type.compute; // it's a static @property function
    ...and the compute functions haven't been implemented by Type,
    they get lowered into free function calls...
    A) compute!(Type)(<ARGUMENTS>);
    B) compute!(Type);

2. Constructors as free functions
    If a constructor call hasn't been implemented by Type...
    auto t = Type(<ARGUMENTS>);
    ...then it get's lowered into a free function call...
    auto t = this!(Type)(<ARGUMENTS>);
    (or something like that)

On 2012-06-17 08:39, Tommi wrote:
> As I see it, the goal of uniform function call syntax, as described here
> http://www.drdobbs.com/blogs/cpp/232700394, is to allow non-intrusively
> extending the functionality of a type. I think the current
> implementation comes short in accomplishing this goal on two accounts:
>
> 1) You can't non-intrusively add static member functions
> 2) You can't non-intrusively add constructors
>
> So, I'm suggesting these two features to be added to the language:
>
> 1. Static method lowering rules
> If function calls like the following are encountered...
> A) Type.compute(<ARGUMENTS>);
> B) Type.compute; // it's a static @property function
> ...and the compute functions haven't been implemented by Type,
> they get lowered into free function calls...
> A) compute!(Type)(<ARGUMENTS>);
> B) compute!(Type);
>
> 2. Constructors as free functions
> If a constructor call hasn't been implemented by Type...
> auto t = Type(<ARGUMENTS>);
> ...then it get's lowered into a free function call...
> auto t = this!(Type)(<ARGUMENTS>);
> (or something like that)

I like that idea.

-- 
/Jacob Carlborg

I posted this as an enhancement request over there:
http://d.puremagic.com/issues/show_bug.cgi?id=8381

Have you considered adding operator overloading using UFCS while you're at it?

On 07/12/2012 12:05 PM, Thiez wrote:
> Have you considered adding operator overloading using UFCS while you're
> at it?

There is already an open issue about that iirc.

On Thursday, 12 July 2012 at 10:05:16 UTC, Thiez wrote:
> Have you considered adding operator overloading using UFCS while you're at it?

I assumed it's already possible to add operators non-intrusively, because operators are just syntactic sugar for method calls:

++var;              // actual code
var.opUnary!"++"(); // lowered once
opUnary!"++"(var);  // lowered twice (if necessary)

If you're talking about overloading existing operators (which have been implemented as member functions) non-intrusively for other types, then I don't know, doesn't it work?

On Thursday, 12 July 2012 at 12:43:24 UTC, Tommi wrote:
> On Thursday, 12 July 2012 at 10:05:16 UTC, Thiez wrote:
>> Have you considered adding operator overloading using UFCS while you're at it?
>
> I assumed it's already possible to add operators non-intrusively, because operators are just syntactic sugar for method calls:
>
> ++var;              // actual code
> var.opUnary!"++"(); // lowered once
> opUnary!"++"(var);  // lowered twice (if necessary)
>
> If you're talking about overloading existing operators (which have been implemented as member functions) non-intrusively for other types, then I don't know, doesn't it work?

I actually tried those yesterday (with opEquals and opCmp on structs) and couldn't get it to work. Code still used what appeared to be an automatically generated opEquals (that appears to perform a bitwise comparison) instead of my UFCS opEquals.

It's already quite obvious that the compiler does not obey its own rewrite rules (see http://dlang.org/operatoroverloading.html#compare) Consider opCmp:
 a < b
is rewritten to
 a.opCmp(b) < 0
or
 b.opCmp(a) > 0
Let's assume the first rule is always chosen. According to the very rewrite rule we just applied, this must be rewritten to
 a.opCmp(b).opCmp(0) < 0
which must be rewritten to
 a.opCmp(b).opCmp(0).opCmp(0) < 0
and then
 a.opCmp(b).opCmp(0).opCmp(0).opCmp(0) < 0
and so on, to infinity.

It seems quite obvious the compiler does not rewrite compares on integers or all hell would break loose... The language reference should be more specific about these things.

On Thursday, 12 July 2012 at 13:19:00 UTC, Thiez wrote:
> It's already quite obvious that the compiler does not obey its own rewrite rules (see http://dlang.org/operatoroverloading.html#compare) Consider opCmp:
>  a < b
> is rewritten to
>  a.opCmp(b) < 0
> or
>  b.opCmp(a) > 0
> Let's assume the first rule is always chosen. According to the very rewrite rule we just applied, this must be rewritten to
>  a.opCmp(b).opCmp(0) < 0
> which must be rewritten to
>  a.opCmp(b).opCmp(0).opCmp(0) < 0
> and then
>  a.opCmp(b).opCmp(0).opCmp(0).opCmp(0) < 0
> and so on, to infinity.
>
> It seems quite obvious the compiler does not rewrite compares on integers or all hell would break loose... The language reference should be more specific about these things.

Quote from 'The D Programming Language' chapter 12.1:
"D’s approach to operator overloading is simple: whenever at least one participant in an operator expression is of user-defined type, the compiler rewrites the expression into a regular method call with a specific name. Then the regular language rules apply."

So, assuming opCmp returns integer, then a.opCmp(b) < 0 doesn't get rewritten (lowered) any further, because user-defined types are not involved.

"Thiez" , dans le message (digitalmars.D:172060), a écrit :
>>> Have you considered adding operator overloading using UFCS while you're at it?
>>
>> I assumed it's already possible to add operators non-intrusively, because operators are just syntactic sugar for method calls:
>>
>> ++var;              // actual code
>> var.opUnary!"++"(); // lowered once
>> opUnary!"++"(var);  // lowered twice (if necessary)
>>
>> If you're talking about overloading existing operators (which have been implemented as member functions) non-intrusively for other types, then I don't know, doesn't it work?
>
> I actually tried those yesterday (with opEquals and opCmp on structs) and couldn't get it to work. Code still used what appeared to be an automatically generated opEquals (that appears to perform a bitwise comparison) instead of my UFCS opEquals.

This behavior for opEquals is debatable, but make sense. If the designer of a struct did not implement opEquals, it may be that he intended opEqual to be the default opEqual. If you overload opEquals for such struct, you may be hijacking it's intended behavior: your not just adding a functionality, your overriding an existing functionality.

Did you try operators that are not automatically generated ?

> It's already quite obvious that the compiler does not obey its
> own rewrite rules (see
> http://dlang.org/operatoroverloading.html#compare) Consider opCmp:
>   a < b
> is rewritten to
>   a.opCmp(b) < 0
> or
>   b.opCmp(a) > 0
> Let's assume the first rule is always chosen. According to the
> very rewrite rule we just applied, this must be rewritten to
>   a.opCmp(b).opCmp(0) < 0
> 
> It seems quite obvious the compiler does not rewrite compares on integers or all hell would break loose... The language reference should be more specific about these things.

The rewrite rule obviously apply only if the comparison operator is not already defined for those types by the langage. That could be precised in the web site, but it's consistent.

By the way, would it be possible to implement an opCmp that returns a double, to allow it to return a NaN ? That may allow to create values that are neither superior, nor inferior to other value, like NaNs. It's not possible to implement opCmp for a floating point comparison if opCmp is bound to return an int.

Another reason to ban Object imposing a specific signature for opCmp in all classes...

On Thursday, 12 July 2012 at 14:31:34 UTC, travert@phare.normalesup.org (Christophe Travert) wrote:
>
> This behavior for opEquals is debatable, but make sense.

I don't think it's debatable at all. You must be able to figure out how a class is going to behave just by looking at its definition.