DIP 1016--ref T accepts r-values--Formal Assessment

Steven Schveighoffer schveiguy at gmail.com
Thu Jan 31 03:31:05 UTC 2019

On 1/30/19 10:05 PM, Manu wrote:
> On Wed, Jan 30, 2019 at 6:40 PM Nicholas Wilson via
> Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>> You should clarify that ;)
> Yes, as said above, read `short(10)`. I can understand the confusion
> that it may look like a variable when taken out of context; but listed
> beneath the heading immediately above which says:
> "This inconvenience extends broadly to every manner of **rvalue**
> passed to functions"
> It didn't occur to me the reader might interpret the clearly stated
> list of cases of rvalues passed to functions to include arguments that
> are not rvalues.
> The name was just chosen to indicate the argument is a short, perhaps
> an enum, or any expression that is a short... I could have used
> `short(10)`, but apparently I didn't think of it at the time.
> Is this the basis for the claims of "a hole you could drive a truck
> through"? Again, a request for clarification, and a
> couldn't-possibly-be-more-trivial revision may resolve this.

I think changing it to `short(10)` helps the argument that you didn't 
intend it to mean conversions from lvalues, but I'd recommend still 
spelling out that they are forbidden.

Leaving the reader to infer intent is not as good as clarifying intent 
directly. The whole rvalue vs. lvalue thing is confusing to me, because 
I assumed an lvalue converted to a different type changes it to an 
rvalue. I think of it like an implicit function that returns that new value.


More information about the Digitalmars-d-announce mailing list