rvalues -> ref (yup... again!)

[Manu]

On 23 March 2018 at 20:17, Timon Gehr via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 24.03.2018 02:16, Manu wrote:
>>
>> This is an interesting point, but I don't think it changes the balance
>> in any way. Thinking of the majority of my anecdotal cases, I don't
>> think it would be a problem.
>> Something complex enough for const to be a problem likely doesn't
>> conform to this pattern.
>
>
> Why aim for "it often works", when we want "it always works"? Forcing const
> upon people who want to pass rvalues by reference is just not good enough.
> It is bad language design.

I think you need to re-read the whole thread, and understand what
we're even talking about.
Nobody wants to pass rvalues by mutable-ref... that's completely
pointless, since it's an rvalue that will timeout immediately anyway.
Passing by const-ref is perfectly acceptable.

I suspect Jonathan's talking about classic D situations with const
like, I might pass by const-ref, but then I can't call a getter that
caches the result.
That's a classic problem with D's const, and that's not on debate
here. I don't think that has any impact on this proposal; people
understand what const means in D, and that's no different here than
anywhere else.


> Also I think the point about documenting mutation intent is moot, as rvalues
> can be receivers for method calls, which will _already_ pass an rvalue by
> reference no matter whether it intends to mutate it or not. We can require
> some special annotation for this behavior, but I'd be perfectly fine without
> it.

I have no idea what this paragraph means... can you elaborate further
what you're talking about?