November 02, 2021
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 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

It's blocking issue 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 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 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?

November 02, 2021

On Tuesday, 2 November 2021 at 10:20:34 UTC, WebFreak001 wrote:

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

It's blocking issue 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 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 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