first draft Reducing the legal permutations of ref-return-scope
Dukc
ajieskola at gmail.com
Tue May 13 15:03:18 UTC 2025
On Tuesday, 13 May 2025 at 04:23:05 UTC, Walter Bright wrote:
> https://github.com/WalterBright/documents/blob/master/ReturnRefScope.md
I think only the meaning of `return`, as in `return scope` or
`return ref`, is the confusing thing. `scope ref` and `ref scope`
without `return` around should both remain allowed since they
mean the same thing, as should both `ref return scope` and
`return scope ref`, plus both `return ref scope` and `scope
return ref`.
The spec curretly say that `return` that is not followed by
`scope` would mean `return ref`. What the spec doesn't say, but
the implementation accepts, is that if the parameter in question
is not `ref`, then `return` means `return scope`.
I think it's the latter part we should get rid of. So that in the
future:
1. `return` without `scope` following always means `return ref`,
like the spec says.
2. However, it is an error if the parameter isn't actually `ref`.
This means that
```D
ref int* fun(return ref scope int*);
ref int gun(scope ref return int*);
struct IntPtr
{ ref Int-ptr memFun() scope return;
}
```
would all be valid, but `ref int hun(scope return int*)` would
not be, unlike now.
More information about the dip.development
mailing list