DIP 1016--ref T accepts r-values--Community Review Round 1

Johannes Loher johannes.loher at fg4f.de
Sun Jul 22 07:58:01 UTC 2018


On Saturday, 21 July 2018 at 08:59:39 UTC, Manu wrote:
> 4. A struct-type getter that returns by-val exhibits this 
> gotcha in a
> variety of ways; you 'get' the member (a by-val copy), then 
> mutate a
> member in any way, (ie, call a method), and you've accidentally
> modified the copy, not the source value! (`ref` is not the bug)
>   - note, in all other constructions of this same 'bug', 
> existing
> language semantics find it acceptable to silently accept the
> accidental mutation of an expiring rvalue. Nobody is losing 
> sleep at
> night.

This argument kind of convinced me. I also just realized, there 
is another such situation which is very similar to functions 
taking ref parameters, where references to rvalues are actually 
allowed: foreach loops. The following code is actually valid, 
which kind of surprised me:

foreach(ref e; iota(0, 10))
{
     e += 1;
}

So DIP 1016 actually seems to make the language more consistent 
in that regard.

I also carefully reread the DIP and found some minor issues:

- "It has been noted that is it possible to perceive the current 
usage of":
it should be "[...] it is [...]

- Somebody already mentioned this, but this sections sounds 
confusing, please find a better wording: "An example may be some 
meta that reflects or receives a function by alias." Also you 
seem to be using "meta" as a noun many times. I'm not totally 
sure, but I don't think it actually is a noun and for the least, 
It is very uncommon as a noun which makes understanding the 
corresponding sections much harder. For example I don't 
understand what is actually meant by "brittle meta" in a later 
section.




More information about the Digitalmars-d mailing list