DIP 1016--ref T accepts r-values--Community Review Round 1

[Manu]

On Wed, 25 Jul 2018 at 04:50, Jim Balter via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Wednesday, 25 July 2018 at 08:34:30 UTC, Manu wrote:
> [snip]
>
> > Meanwhile I think we have determined that the presumed
> > practical trouble
> > cases are even less that I suspected up front.
>
> That's surprising; I didn't realize that you suspected practical
> trouble cases.

My initial draft was written for 'ref const T ', and that was a
conservative choice because I felt the same unsubstantiated fear.
I think it's like this; there is a presumption that the feature was
made that way for a reason... so it *must* be protecting us against
something that it was designed to protect us against, right?

Others argued to remove the 'const' from my proposal, and then the
more I thought on that, and followed various experiments through, I
realised that my fears were unsubstantiated (I couldn't dream up
legitimate problem cases), and that mutable ref brought significant
additional value which actually strengthen the DIP substantially.

I still suspect it's possible to contrive a case where a bug may be
caught by the existing mechanic, but what we have determined by
following some of these cases presented here is that they're far less
likely than even I initially _imagined_ (yes, still working from the
same unsubstantiated fear), or that the bugs are actually unrelated
issues which should be addressed separately.


For instance, I can imagine a DIP to address the property concern that
we have identified here:

** Mutable-but-also-byval properties (ie, a property with a by-val
getter and also a setter) do not behave like a user expects when
supplied as ref arguments.
** Situation: a by-val getter passes an rval to a ref arg, which may
be mutated, and the results are lost.
** Propose: after the function call concludes, call the properties
setter, supplying the potentially mutated rval that the getter
returned.

This very simple semantic will cause non-ref properties to function
correctly even in the context of by-val getting and ref.
I actually think this is a very elegant solution to a wider class of
problem with properties.

...but this comment is dangerous. I REALLY don't want this point to
lead off on a tangent ;)
*considers deleting post... but clicks send anyway...*