Thread overview
[Issue 22769] `fun()` where fun is a property which returns an object with opCall should call opCall
Feb 13, 2022
Basile-z
Feb 13, 2022
Vladimir Panteleev
Feb 13, 2022
Basile-z
Feb 14, 2022
anonymous4
Feb 14, 2022
Vladimir Panteleev
Feb 14, 2022
anonymous4
Feb 14, 2022
anonymous4
Feb 14, 2022
anonymous4
Dec 17, 2022
Iain Buclaw
February 13, 2022
https://issues.dlang.org/show_bug.cgi?id=22769

Basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com

--- Comment #1 from Basile-z <b2.temp@gmx.com> ---
what is the background idea ? Is this proposal a way to have opCall called without explicit CallExp ?

---
struct S
{
    void opCall() @property
    {
    }
}

S s;

@property S fun()
{
    return s;
}

void main()
{
    s(); // ok
    s;   // using @property of opCall, that cannot work
    fun; // works using semantics proposed in bugzilla 22769
}
---

--
February 13, 2022
https://issues.dlang.org/show_bug.cgi?id=22769

--- Comment #2 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
(In reply to Basile-z from comment #1)
> what is the background idea ?

Making @property do its job

> Is this proposal a way to have opCall called without explicit CallExp ?

No. () is the CallExp. It should be applied to the return value, not the property. Without @property, the code should behave as it does now.

--
February 13, 2022
https://issues.dlang.org/show_bug.cgi?id=22769

--- Comment #3 from Basile-z <b2.temp@gmx.com> ---
Thanks for the explanations, I see the issue now, that is that opCall is not tried.

--
February 14, 2022
https://issues.dlang.org/show_bug.cgi?id=22769

--- Comment #4 from anonymous4 <dfj1esp02@sneakemail.com> ---
This is called "strict properties" and requires a DIP, especially since previous DIPs about this went nowhere and people in general gave up on sorting this out. But maybe it's a good time for a new DIP. Among other things to prohibit stuff like module-level strict extension properties.

--
February 14, 2022
https://issues.dlang.org/show_bug.cgi?id=22769

--- Comment #5 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
It has been a while, and I think the strict properties DIPs were about entirely forbidding "someProperty()"; whereas in this case, it may make more sense for incremental improvement in the form of fixing only syntax which is "ambiguous" like it is here.

--
February 14, 2022
https://issues.dlang.org/show_bug.cgi?id=22769

--- Comment #6 from anonymous4 <dfj1esp02@sneakemail.com> ---
Currently it works according to optional parentheses, which is not ambiguous, since strict properties obviously aren't implemented. If you want to introduce strict properties gradually, it's a DIP too, what to introduce gradually.

--
February 14, 2022
https://issues.dlang.org/show_bug.cgi?id=22769

--- Comment #7 from anonymous4 <dfj1esp02@sneakemail.com> ---
But, yeah, presumably it should deprecate a bunch of stuff first.

--
February 14, 2022
https://issues.dlang.org/show_bug.cgi?id=22769

--- Comment #8 from anonymous4 <dfj1esp02@sneakemail.com> ---
If deprecation goes successfully, it may open possibility for implementation of strict properties.

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=22769

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--
December 13
https://issues.dlang.org/show_bug.cgi?id=22769

--- Comment #9 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dmd/issues/20051

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--