• WebFreak001 (39/39) Nov 02 2021 ```d
• 12345swordy (17/59) Nov 02 2021 The reason why my PR wasn't merged is because it needs a DIP.

WebFreak001 <d.forum webfreak.org> writes:

```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?

12345swordy <alexanderheistermann gmail.com> writes:

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