On request by Maxim Fomin I ask an opinion here. This is a very small enhancement request, that for me is borderline bug report (so originally I didn't plan in showing it in the main D newsgroup):

http://d.puremagic.com/issues/show_bug.cgi?id=9857



Maybe this should be valid:


struct Foo {
    int opCall(bool b) {
        return 0;
    }
}
void main() {
   Foo foo;
   auto b1 = foo(true); // OK
   auto b2 = true.foo;  // Error
}


dmd 2.063alpha gives:

temp.d(9): Error: no property 'foo' for type 'bool'


Explanation:

1) I am using UFCS often in D, for functions, higher order functions, etc. A struct with an opCall method is usable like a function with state. So for uniformity with the other functions I'd like to use it with UFCS. When you have a long UFCS chain you don't want to break it, if it's possible.


2) Both struct constructors, struct implicit constructors and struct static opCall support UFCS, so I don't see a good reason for just the normal struct opCall to not support it:


struct Foo {
    static int opCall(int x) {
        return x * 2;
    }
}
struct Bar {
    int x;
    this(int y) {
        x = y * 2;
    }
}
struct Spam {
    int x;
}
void main() {
    assert(10.Foo == 20);
    assert(10.Bar.x == 20);
    assert(10.Spam.x == 10);
}


Jonathan Davis doesn't like this. For more information I suggest to take a look at the thread in Bugzilla.

- - - - - - - - - - -

Regarding UFCS, currently this doesn't work, I don't know if this should be considered a bug or not (I think the answer is positive):


struct Node {}
void foo(Node* p) {}
void main() {
    auto p = new Node();
    foo(p); // OK
    p.foo;  // Error: no property 'foo' for type 'Node'
}


Bye,
bearophile

I see no issue with the request, I've never used a non-static opcall, seems odd, but for a uniform syntax I'd say go for it.

> - - - - - - - - - - -
>
> Regarding UFCS, currently this doesn't work, I don't know if this should be considered a bug or not (I think the answer is positive):
>
>
> struct Node {}
> void foo(Node* p) {}
> void main() {
>     auto p = new Node();
>     foo(p); // OK
>     p.foo;  // Error: no property 'foo' for type 'Node'
> }
>
>
> Bye,
> bearophile

D has specified that . (dot) will dereference, I don't see this as a bug. What do you think should happen if you do have a foo(Node p) {}? Now on to Some points from the BZ entry.

Jonathan, UFCS was never planned for arrays, the only reason the bug wasn't fixed was because it was nice and figured it should be expanded upon. Planning for it to only work with arrays would just be weird.

Andrej, The statement related to reversing foo(a) means that you don't get a.foo(), since bearophile is requesting this it should try foo(a). Also about how long we have had UFCS:
http://d.puremagic.com/issues/show_bug.cgi?id=662

This jira you reference is commented with: "UFCS for all basic types and enums is implemented in dmd 2.059." which was released in April last year. The oldest bug you mention is for the array "version."

UFCS should just work only for 'functions'.
'foo' is not a function, rather it is a functor. So this is proper behavior.

Kenji Hara

2013/4/9 bearophile <bearophileHUGS@lycos.com>

> On request by Maxim Fomin I ask an opinion here. This is a very small enhancement request, that for me is borderline bug report (so originally I didn't plan in showing it in the main D newsgroup):
>
> http://d.puremagic.com/issues/**show_bug.cgi?id=9857<http://d.puremagic.com/issues/show_bug.cgi?id=9857>
>
>
>
> Maybe this should be valid:
>
>
> struct Foo {
>     int opCall(bool b) {
>         return 0;
>     }
> }
> void main() {
>    Foo foo;
>    auto b1 = foo(true); // OK
>    auto b2 = true.foo;  // Error
> }
>
>
> dmd 2.063alpha gives:
>
> temp.d(9): Error: no property 'foo' for type 'bool'
>
>
> Explanation:
>
> 1) I am using UFCS often in D, for functions, higher order functions, etc. A struct with an opCall method is usable like a function with state. So for uniformity with the other functions I'd like to use it with UFCS. When you have a long UFCS chain you don't want to break it, if it's possible.
>
>
> 2) Both struct constructors, struct implicit constructors and struct static opCall support UFCS, so I don't see a good reason for just the normal struct opCall to not support it:
>
>
> struct Foo {
>     static int opCall(int x) {
>         return x * 2;
>     }
> }
> struct Bar {
>     int x;
>     this(int y) {
>         x = y * 2;
>     }
> }
> struct Spam {
>     int x;
> }
> void main() {
>     assert(10.Foo == 20);
>     assert(10.Bar.x == 20);
>     assert(10.Spam.x == 10);
> }
>
>
> Jonathan Davis doesn't like this. For more information I suggest to take a look at the thread in Bugzilla.
>
> - - - - - - - - - - -
>
> Regarding UFCS, currently this doesn't work, I don't know if this should be considered a bug or not (I think the answer is positive):
>
>
> struct Node {}
> void foo(Node* p) {}
> void main() {
>     auto p = new Node();
>     foo(p); // OK
>     p.foo;  // Error: no property 'foo' for type 'Node'
> }
>
>
> Bye,
> bearophile
>
'

On 04/09/2013 01:48 AM, bearophile wrote:
> On request by Maxim Fomin I ask an opinion here. This is a very small
> enhancement request, that for me is borderline bug report (so originally
> I didn't plan in showing it in the main D newsgroup):
>
> http://d.puremagic.com/issues/show_bug.cgi?id=9857
> ...

This is getting old. We should discuss the general issue, issue 9857 is just another instance of it.

Namely:

If the language defines a rewrite from A to B and from B to C, is a rewrite from A to C implied?

I'd say yes, because this is the obvious behaviour. If it is not there, we have to add a magical "has already been rewritten" flag, countering intuition. Furthermore, as far as I am concerned, this is easier to implement. DMD's inconsistent behaviour has been discussed on d.D.learn multiple times.

Furthermore, the only argument brought up against this so far is that some language constructs are special and ergo they must be mutually incompatible. This is a complete non sequitur.

>
> Jonathan Davis doesn't like this. For more information I suggest to take
> a look at the thread in Bugzilla.
> ...

There is not more information there, it's just given in a blown up representation. He does not justify his opinion.

On 04/09/2013 05:49 AM, kenji hara wrote:
> UFCS should just work only for 'functions'.

Why? This is a superfluous complication that does not buy anything.

> 'foo' is not a function, rather it is a functor. So this is proper behavior.
> ...

There is no spec, therefore calling any behaviour proper without supporting arguments is meaningless.

On 04/09/2013 11:13 AM, Timon Gehr wrote:
> On 04/09/2013 05:49 AM, kenji hara wrote:
>> UFCS should just work only for 'functions'.
>
> Why? This is a superfluous complication that does not buy anything.
> ...

Furthermore, this rule excludes function templates from UFCS.

For sake of uniformity, UFCS should apply everywhere as a general re-write rule, not just on functions.

a.b(args...) should first check for non-UFCS definition, then for b(a,args...):
condition.assert;
string.mixin
expression.typeof

it makes chaining easier, intermediate variables un-necessary, and maybe even implementation easier since the rule would be general.

On Monday, 8 April 2013 at 23:48:13 UTC, bearophile wrote:
> On request by Maxim Fomin I ask an opinion here. This is a very small enhancement request, that for me is borderline bug report (so originally I didn't plan in showing it in the main D newsgroup):
>
> http://d.puremagic.com/issues/show_bug.cgi?id=9857
>
>
>
> Maybe this should be valid:
>
>
> struct Foo {
>     int opCall(bool b) {
>         return 0;
>     }
> }
> void main() {
>    Foo foo;
>    auto b1 = foo(true); // OK
>    auto b2 = true.foo;  // Error
> }
>
>
> dmd 2.063alpha gives:
>
> temp.d(9): Error: no property 'foo' for type 'bool'
>
>
> Explanation:
>
> 1) I am using UFCS often in D, for functions, higher order functions, etc. A struct with an opCall method is usable like a function with state. So for uniformity with the other functions I'd like to use it with UFCS. When you have a long UFCS chain you don't want to break it, if it's possible.
>
>
> 2) Both struct constructors, struct implicit constructors and struct static opCall support UFCS, so I don't see a good reason for just the normal struct opCall to not support it:
>
>
> struct Foo {
>     static int opCall(int x) {
>         return x * 2;
>     }
> }
> struct Bar {
>     int x;
>     this(int y) {
>         x = y * 2;
>     }
> }
> struct Spam {
>     int x;
> }
> void main() {
>     assert(10.Foo == 20);
>     assert(10.Bar.x == 20);
>     assert(10.Spam.x == 10);
> }
>

I don't think this makes any sense. Constructor are not regular function. The bug lies in the fact that this work and not in the opCall not working IMO.

> Regarding UFCS, currently this doesn't work, I don't know if this should be considered a bug or not (I think the answer is positive):
>
>
> struct Node {}
> void foo(Node* p) {}
> void main() {
>     auto p = new Node();
>     foo(p); // OK
>     p.foo;  // Error: no property 'foo' for type 'Node'
> }
>

It is unspecified if the UFCS lookup happen before or after pointer dereference, or both.

On 04/09/2013 12:21 PM, deadalnix wrote:
>...
>
> I don't think this makes any sense. Constructor are not regular
> function. The bug lies in the fact that this work and not in the opCall
> not working IMO.
> ...

On 04/09/2013 11:03 PM, Timon Gehr wrote:
> Furthermore, the only argument brought up against this so far is that some
> language constructs are special and ergo they must be mutually incompatible.
> This is a complete non sequitur.

I still do not get what this is about.

On 04/09/2013 02:40 PM, Timon Gehr wrote:
> On 04/09/2013 12:21 PM, deadalnix wrote:
>> ...
>>
>> I don't think this makes any sense. Constructor are not regular
>> function. The bug lies in the fact that this work and not in the opCall
>> not working IMO.
>> ...
>
> On 04/09/2013 11:03 PM, Timon Gehr wrote:

That's "AM".

>> Furthermore, the only argument brought up against this so far is that
>> some
>> language constructs are special and ergo they must be mutually
>> incompatible.
>> This is a complete non sequitur.
>
> I still do not get what this is about.