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