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

           Summary: UFCS for struct opCall
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2013-04-02 04:10:36 PDT ---
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'

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #1 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-04-02 06:47:33 PDT ---
That seems like a stretch.. why would you need this?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #2 from bearophile_hugs@eml.cc 2013-04-02 10:11:00 PDT ---
(In reply to comment #1)
> That seems like a stretch.. why would you need this?

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 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);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #3 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-04-02 10:41:50 PDT ---
(In reply to comment #2)
> 2) Both struct constructors, struct implicit constructors and struct static opCall support UFCS, so I don't see a good reason for the normal struct opCall to not support it:

I had no idea these worked. I'm really wondering whether this was introduced on purpose..

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #4 from bearophile_hugs@eml.cc 2013-04-02 11:18:28 PDT ---
(In reply to comment #3)

> I had no idea these worked. I'm really wondering whether this was introduced on purpose..

They are useful to not break UFCS chains.

I'd even like typeof() to be usable with that trailing syntax, like sizeof, see
Issue 4272

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #5 from bearophile_hugs@eml.cc 2013-04-02 13:34:00 PDT ---
(In reply to comment #4)

> I'd even like typeof() to be usable with that trailing syntax, like sizeof, see
> Issue 4272

The U of UFCS means universal. And ctors too are functions. So it's expected.

This silly example of random bigint creation shows why they are handy in UFCS chains:


import std.stdio, std.bigint, std.algorithm, std.random,
       std.ascii, std.range, std.array;

void main() {
    auto b1 = 20.iota.map!(_ => digits[uniform(0, $)]).array.BigInt;
    b1.writeln;
}


Long UFCS chains are better written in columns, like in F# language:

auto b1 = 20
          .iota
          .map!(_ => digits[uniform(0, $)])
          .array
          .BigInt;


If struct ctors don't support UFCS you have to wrap everything in a BigInt, and it gets harder to read:

    auto b1 = BigInt(20.iota.map!(_ => digits[uniform(0, $)]).array);


And those columns look bad:

    auto b1 = BigInt(20
                     .iota
                     .map!(_ => digits[uniform(0, $)])
                     .array
                     .BigInt);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #6 from bearophile_hugs@eml.cc 2013-04-02 13:34:54 PDT ---
(In reply to comment #5)

> And those columns look bad:
> 
>     auto b1 = BigInt(20
>                      .iota
>                      .map!(_ => digits[uniform(0, $)])
>                      .array
>                      .BigInt);

Sorry, I meant:

    auto b1 = BigInt(20
                     .iota
                     .map!(_ => digits[uniform(0, $)])
                     .array);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|x86                         |All
         OS/Version|Windows                     |All


--- Comment #7 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-04-02 14:06:44 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> 
> > I'd even like typeof() to be usable with that trailing syntax, like sizeof, see
> > Issue 4272
> 
> The U of UFCS means universal. And ctors too are functions.

Well it probably stands for uniform, but I guess both are true.

> auto b1 = 20
>           .iota
>           .map!(_ => digits[uniform(0, $)])
>           .array
>           .BigInt;

That looks great.

> So it's expected.

I don't have a problem with the feature (it actually looks great with the ctor example you gave there), but it's hard to say what's expected when there's ZERO documentation for UFCS in the spec, which is ridiculous since we've had this feature for the last several years and it has just expanded in functionality ever since. Even TDPL barely talks about UFCS, and calls them "pseudo members".

I really wish people who implement language features spent 10 minutes of their time writing documentation about it. As it stands, it seems only compiler hackers seem to know what language features actually exist and are expected to work.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #8 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-04-02 16:51:22 PDT ---
Personally, it feels very wrong to me that UFCS would work with constructors. It's one thing to use it with normal free functions. It's quite another to do stuff like this.

> I don't have a problem with the feature (it actually looks great with the ctor example you gave there), but it's hard to say what's expected when there's ZERO documentation for UFCS in the spec, which is ridiculous since we've had this feature for the last several years and it has just expanded in functionality ever since. Even TDPL barely talks about UFCS, and calls them "pseudo members".

UFCS and pseudo members are two very different things as similar as they may appear. Arrays had UFCS. That was it. That was all that was ever planned for, and it may have been an accident that it worked in the first (I don't recall for sure). Some tried to claim that TDPL said that it was in the language, but all TDPL ever talked about was arrays, because that's all that there was and all that was planned for. The only reason that it was ever expanded beyond arrays was because people kept asking for it. It hasn't existed for very long, and it was never really planned out AFAIK. Certainly, stuff like whether it should work with overloaded operators or constructors or anything other than basic free functions was never discussed or designed. It was just implemented with the idea that it would work with free functions like arrays had been doing, and the implications of that and the various corner cases were not necessarily considered or examined in detail.

So, if anything, the problem is that the feature was ever implemented without being designed first, and while it _should_ be properly documented by now, it's also a semi-recent feature, so it's not particularly surprising that it's not given how things work around here. But it _has_ been months (probably over a year now, though I'm not sure) since it was introduced, so there's really not much excuse for it not being documented other than the fact that the spec is rarely kept up-to-date (which is just indicative of a larger problem).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

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



--- Comment #9 from bearophile_hugs@eml.cc 2013-04-02 17:19:23 PDT ---
(In reply to comment #8)
> Personally, it feels very wrong to me that UFCS would work with constructors.

Do you want to explain why?

(Constructors are functions, so why introduce an asymmetry.)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------