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

[Manu]

On Wed, 25 Jul 2018 at 10:45, Atila Neves via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Saturday, 21 July 2018 at 08:59:39 UTC, Manu wrote:
> > [...]
> > 3. Scenario depends on introduction of a getter, but any getter
> > property that returns a member by-val is almost certainly a
> > primitive
> > type. A getter for a struct member would necessarily return a
> > ref, or
> > it would experience large copy semantics every time the get is
> > called!
>
> This is assuming anything that isn't a primitive is a large
> struct that is copied, which, in my experience, is rarely the
> case.

But my point is, that exact reasoning extends to the hypothetical ref
argument as the return value.
If a property function sees fit to return by-value (ie, struct is
small), then a function receiving that object will also receive the
argument by-value.

This will be the usual pattern. When a type becomes large enough to
want to pass it by ref, any property that returns one will also most
likely return by ref.
I'm trying to say that, a mismatch is naturally unlikely to occur. And
very unlikely occur *by accident*; it would be a design intent.

> I don't recall ever implementing a getter in D that returns by
> ref. I'd consider that a code smell in pretty much every
> language, allowing mutation from the outside.

Such a getter would likely return const ref, but discussions about
proper use of 'const' are not on topic here.

> For context, I
> think that getters are a faint code smell and that setters always
> stink.

So, you're reducing the power of the properties argument in principle?

> All of this to say that I disagree that getters will usually
> return by ref unless the return type is a primitive. That's not
> how I write code and I don't remember encountering this in the
> wild.

Agreed. My above amendment should be a more accurate tendency, which
is what I was trying to express, but in too-few words.

> > (`ref` is not the bug)
> >   - note, in all other constructions of this same 'bug',
> > existing
> > language semantics find it acceptable to silently accept the
> > accidental mutation of an expiring rvalue. Nobody is losing
> > sleep at
> > night.
>
> That's because T().mutate() is obviously not going to do
> anything. Nobody would expect it to.

Of course `T().mutate()` is obvious, but `s.member.mutate()` (where
member is property) might be misunderstood to do something. I don't
see how the exact set of arguments being applied to ref don't apply
here (and many other possible cases).

> > The same 'bug' expressed in a simpler and more likely way:
> >
> > // a struct that shall be the member
> > struct M {
> >   int x;
> >   void mutate() { ++x; }
> > }
> >
> > // the original (working) code
> > struct S {
> >   M member;
> > }
> > S s;
> > s.member.mutate();
>
> It'd take roughly 5s between me seeing this in code review and
> typing the words "Law of Demeter violation". To me that's TRWTF.

I don't understand what you're saying here?
I think this case is equally hard to spot as the
passing-property-as-ref-arg case.

Either way, the solution to this whole branch of discussion lies with
property, not with ref (and I've given some ideas).