5 months ago I described an issue with ref return scope
parameters:
DIP1000: 'return scope' ambiguity and why you can't make opIndex work
(N.b. in struct member functions, the this
keyword is a ref
parameter)
The gist of it is that the return
keyword both appears in return ref
and return scope
, but currently the parser doesn't look at the ordering of the ref
return
scope
keywords, so the decision is made by this rule:
- If the function returns by
ref
, it favorsreturn ref
, otherwise it favorsreturn scope
.
What if you want to return a slice element by ref
or return a ref
as a slice? Tough luck.
But wait, that rule is only what the specification says should happen. dmd actually has its own ways of choosing between return ref
and return scope
:
Consider the following types:
P contains indirections
I does not contain indirections
X may or may not contain indirections
Currently, the ambiguity is resolved:
a. P foo(ref return scope P p) => ref returnScope
b. I foo(ref return scope P p) => returnRef scope (!!)
c. ref X foo(ref return scope P p) => returnRef scope
d. X foo(ref return scope I) => returnRef (!!)
e. ref X foo(ref return scope I) => returnRef
Walter describes this existing behavior, as well as a proposed solution to explicitly allow the missing cases, in this bugzilla issue:
Issue 22541 - DIP1000: Resolve ambiguity of ref-return-scope parameters
What do you think of this proposal?