digitalmars.D.bugs - [Issue 22541] New: Resolve ambiguity of ref-return-scope parameters
- d-bugmail puremagic.com (40/40) Nov 23 2021 https://issues.dlang.org/show_bug.cgi?id=22541
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 puremagic.com Reporter: bugzilla 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. --
Nov 23 2021