[Issue 22541] New: Resolve ambiguity of ref-return-scope parameters

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=22541

          Issue ID: 22541
           Summary: Resolve ambiguity of ref-return-scope parameters
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: dmd
          Assignee: nobody at puremagic.com
          Reporter: bugzilla at digitalmars.com

When a function parameter is declared as `ref return scope`, is it `return
ref`, or `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

d,e are explained in terms of `scope` being dropped because it makes no sense
if I contains no indirections. The trouble comes into play when a generic type
T is used, and the `return` attribute moves surprisingly back and forth between
the `ref` and the `scope`. b is explained because since a pointer is not being
returned, there's no reason for `scope` to be `return`. Again, generic code can
have surprising behavior. a,c cause problems because converting a pointer
to/from a ref is legitimate in @system code.

`ref` `return` and `scope` can appear in any order, and intermingled with other
attributes like `const`. They cannot appear more than once.

This proposal is that if `return` and `ref` appear adjacent to each other, in
this order, then the result is returnRef. Similarly, `return` and `scope`
become returnScope. If neither of these two patterns appear, the behavior
remains the same as in a..e.

Having `returnRef` and `returnScope` remains illegal.

--