On Friday, July 20, 2018 11:50:41 Manu via Digitalmars-d wrote: > > I am completely against allowing ref to accept rvalues without some sort > > of attribute indicating that it should be allowed to (e.g. @rvalue > > ref). > I sincerely hope you're in the minority :( > > > Allowing ref to accept rvalues goes completely against the idea that ref > > is for passing an object so that it can be mutated and have its result > > affect the caller. > > That is *one use* for ref. I produced text to the effect of changing > your mental model and such assertions.
It's the primary use for ref as it stands given that ref does not currently accept rvalues, and personally, when I use ref on a function, it's a very specific API decision where it really does not make sense to accept lvalues. It's also how plenty of other folks use ref (e.g. it's generally how Phobo uses ref). This DIP doesn't change any of that. It just makes it harder in favor of providing a way to pass rvalues by ref. IMHO, those two use cases are distinct and should be distinct in the API. Using @disable as the DIP suggests is ridiculously verbose in comparison to how ref currently works, and it would require updating many existing uses of ref just to avoid the bugs caused by accepting rvalues. IMHO, it makes far more sense to require an explicit attribute to indicate that a parameter accepts rvalues. It's less error-prone, less verbose, and doesn't cause problems for existing code. > "This DIP proposes that we reconsider the choice to receive an > argument by value or by reference as a detail that the API *author* > selects with respect to criteria relevant to their project or domain." > > Could I improve communication of that sentiment? The reality of the matter is that it's always going to be up to the API author on some level - e.g. even if the proposed changes were implemented, there's still the question of whether a function's parameter should be marked with ref or not, and arguably, in general, it really shouldn't be, because it destroys the compiler's ability to move. Yes, by either allowing ref to accept rvalues or by adding an attribute like @rvalue to make ref accept rvalues, it's then up to the caller as to whether they pass an lvalue or rvalue, but it's still up to the API designer to decide how values are passed, and in some cases, it really does matter whether rvalues are accepted or not. - Jonathan M Davis
