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