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. 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. 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. - Jonathan M Davis
