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

[Atila Neves]

On Wednesday, 25 July 2018 at 18:37:55 UTC, Manu wrote:
> 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:

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

That's a good point. I mean, with code not under one's control it 
could happen otherwise, but most likely not.

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

Yep.

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

Yes, as long as it's code I write or review.


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

That unless it's a UFCS chain there shouldn't be more than one 
dot. One should attempt to not call functions on returned 
members. It should be `s.mutate()` where `member` is aliased this 
or has `mutate` manually forwarded.

That is: don't "reach in" to objects, it's bad design anyway and 
the bug doesn't exist if you don't.