DIP1000: Walter's proposal to resolve ambiguity of ref-return-scope parameters

[Walter Bright]

On 11/24/2021 9:02 PM, Paul Backus wrote:
> IMO we should only do this if we also apply it to `return ref`,

The proposal already does that.

> and deprecate 
> the `return` attribute in any position other than immediately before `ref` or 
> `scope`—i.e., we essentially make `return ref` and `return scope` into "compound 
> keywords".

That's the longer term goal. But meanwhile, I don't want to break too much 
existing code.

> Another thing I'd like to see addressed by this (or any) proposal is how it 
> interacts with attribute inference. Do these new combinations *only* work when 
> the attributes are explicitly given, rather than inferred?

They'll be inferred. Otherwise, attribute inference is useless.

> If so, that will mean 
> that they cannot be used in many cases for generic code—e.g., if my template 
> function may call a user-defined copy constructor of some generic type `T`, I 
> cannot manually mark that parameter as `return scope`, since I do not know in 
> advance whether the copy constructor conforms to those attributes.

I.e. useless :-)