UFCS for struct opCall?

[deadalnix]

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.