Comment #0 by dlang-bugzilla — 2022-02-13T18:28:37Z
///////////////// test.d ////////////////
bool called;
struct S
{
void opCall()
{
called = true;
}
}
@property S fun()
{
return S.init;
}
static assert(is(typeof(fun()) == void));
/////////////////////////////////////////
With @property, the () should be applied to the property return value.
To avoid suddenly breaking code, we can first deprecate and then hard-error on expressions which are "ambiguous" in this way.
Comment #1 by b2.temp — 2022-02-13T19:24:28Z
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
}
---
Comment #2 by dlang-bugzilla — 2022-02-13T19:27:00Z
(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.
Comment #3 by b2.temp — 2022-02-13T21:00:03Z
Thanks for the explanations, I see the issue now, that is that opCall is not tried.
Comment #4 by dfj1esp02 — 2022-02-14T08:36:42Z
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.
Comment #5 by dlang-bugzilla — 2022-02-14T14:53:32Z
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.
Comment #6 by dfj1esp02 — 2022-02-14T15:32:55Z
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.
Comment #7 by dfj1esp02 — 2022-02-14T15:34:31Z
But, yeah, presumably it should deprecate a bunch of stuff first.
Comment #8 by dfj1esp02 — 2022-02-14T15:36:53Z
If deprecation goes successfully, it may open possibility for implementation of strict properties.
Comment #9 by robert.schadek — 2024-12-13T19:20:55Z