will we be getting @property l-values?

[12345swordy]

On Tuesday, 2 November 2021 at 10:20:34 UTC, WebFreak001 wrote:
> ```d
> struct Foo
> {
>     int _x = 4;
>     int x() const @property { return _x; }
>     int x(int value) @property { return _x = value; }
> }
>
> void main()
> {
>     Foo foo;
>     foo.x += 2; // <- breaks because of separate x getter & 
> setter, currently needs workarounds like operator overloading 
> or returning a `ref` variable
> }
> ```
>
> this has been point of discussion a few times [at least since 
> 2012](https://forum.dlang.org/post/xcbweciovapinaicxgbn@forum.dlang.org) and I don't think there were any big problems that came up in these discussions except for some discussions about detailed semantics about caching/copying that did have logical solutions.
>
> There is also a enhancement open on bugzilla since that same 
> thread [that is still open 
> today](https://issues.dlang.org/show_bug.cgi?id=8006)
>
> It's blocking [issue 
> 16187](https://issues.dlang.org/show_bug.cgi?id=16187) and 
> potentially libraries, especially GUI libraries, having nicer 
> property syntax and the properties being more idiomatically 
> used.
>
> This was once implemented by [JinShil's pull 
> request](https://github.com/dlang/dmd/pull/7079) but taking 
> over a year of review it was eventually closed as the 
> contributor also left D around the time, possibly due to 
> personal reasons and maybe work as well, leaving the PR no 
> longer maintained.
>
> There is now a [new PR by 
> 12345swordy](https://github.com/dlang/dmd/pull/12097) which 
> picks up these changes though. It has already been open since 
> the start of the year and there is still (but only a little) 
> activity on it.
>
> These PRs take too long to get merged in IMO. Contributors time 
> is also not infinite and having a change that shouldn't really 
> be that impactful or problematic being stalled over a year in 
> both cases is not that good.
>
> What could we do to speed up changes like this, which attempt 
> to add 8 year old enhancements, and help the contributors?

The reason why my PR wasn't merged is because it needs a DIP. 
Which during my rough draft of the DIP I realized that using 
@property tag isn't going to cut it, as the changes that I have 
in mind will require major breakage to existing code if I attempt 
to used the existing @property tag. I rather avoid that and 
introduce @get and @set attributes for library managers to 
replace @property incrementally, then years down the line, 
@property will be deprecated and no longer considered to be 
system attribute.

Right now, my main focus is managing the rvalue dip which I 
considered to be way overdue in terms of being submitted. That 
dip needs to go first before I submit my dip as it deals with 
binding rvalues to ref paramaters, in which my DIP does NOT allow 
binding rvalues to ref parameters from functions that is marked 
with the @get tag, as I considered it to be a accessor function.

-Alex