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

[Manu]

On 30 March 2018 at 16:09, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Friday, March 30, 2018 14:47:06 Manu via Digitalmars-d wrote:
>> On 30 March 2018 at 12:24, Jonathan M Davis via Digitalmars-d
>> > I want to be able to look at a function signature, see ref without other
>> > qualifiers, and be reasonably certain that the function is supposed to
>> > be
>> > mutating that argument, whereas if ref by itself accepted rvalues, then
>> > we lose that. If an attribute were used to make it allow rvalues, then
>> > we wouldn't.
>>
>> I don't know any reason why someone wouldn't attribute the argument
>> 'const' if it doesn't intend to write to it. Likewise 'return ref' if
>> it's going to be modified and returned.
>> I'm not sure your concern is actually a thing...?
>
> const would do it, but given how restrictive const is in D, I don't see how
> it would be very reasonable to restrict passing rvalues to const.

I'm actually coming around to the idea of not restricting it to const...
But what I'm trying to say is, the number of cases where your
principle will feel violated should be as infrequent as the cases
where const is insufficient for 'reasons' ;)
As far as I know, in usages that I've ever encountered, I can't
imagine a case where you would feel violated :)


> And honestly, I don't really want to encourage the use of const. It's fine if
> folks use it where it really works, and it's potentially even quite valuable
> there, but it seems like too often folks try to add const in places where
> it's just going to cause problems. It's particularly bad when folks try to
> add const to generic code - e.g. we recently had to revert a commit to
> std.random which worked with dynamic arrays but not other ranges because of
> const. And there have been other cases where folks have wanted to try to
> make stuff in Phobos "const-correct", which would cause problems. So, I'm
> not a big fan of the idea of doing anything that would make folks want to
> use const more.

It's interesting... I recognise the general backlash against const. I
personally just make myself a `struct Mutable(T) { ... }` which I use
when I want to violate const ;)
But if it turns out that const is useless, then we really need to
reconsider the basic design of const >_<
Like, what's the point? You're advocating active discouragement of
const... why is there a feature which it's accepted is a loaded-gun?
Handing it to people creates a high probability they'll shoot
themselves in the feet.


> Now, if you can convince Walter and Andrei to allow const ref to accept
> rvalues, then fine. I think that that's definitely worse than an attribute
> specifically for that, given how limiting const is, but it wouldn't screw up
> normal ref in the process, which is what I'm most worried about here. So, I
> don't think that going with const would be the best solution to the problem,
> but it's far better than making ref in general accept rvalues.

Useful examples using 'return ref' have been presented, which I find
quite compelling too. That's an interesting case of non-const ref.
Safe to say I'm not convincing anyone of anything in any way other
than DIP form.


But I'd like to understand your concern better. You say it's about
scanning an API and understanding some details from it based on seeing
'ref' written there... how does a function accepting an rvalue
interact with your visibility of the API?
Like, your criticism is with respect to understanding the API at a
glance... I don't understand how this proposal interferes with that in
any way?

Sadly, I don't think I'll be able to make it to DConf this year...
which is probably a reason for rejoice of literally everybody
attending! :P
It would be nice to workshop it in person though.