On 6/18/2021 8:44 AM, Dennis wrote:
> Here's the reduced code:
> ```D
> struct Vector {
>      float[] _elements;
>      ref float opIndex(size_t i) scope return {
>          return this._elements[i];
>      }
> }
> ```

It *always* helps to reduce these examples to the bare minimum, i.e. strip all the higher level constructs out. The compiler absolutely must be consistent in this. The above reduces to:

  ref int test(ref scope return int* p)
  {
     return *p;
  }

Take a moment to satisfy yourself that it is logically the same. [] was replaced by *, float by int, i no longer needed, don't confuse things with operator overloading, replace `this` with a ref parameter making it a non-member function, and then strip away the struct wrapper.

This currently compiles with master and -dip1000 without error.

Examining Dennis' table, it has a [ref return type] and a [scope value], and so the `return` applies to the pointer type.

And so it is working as intended and is not a bug.

I totally understand that this is headache-inducing. The aspirin is realizing that 100% of these examples can be rewritten using *only* the following terms:

    int i;
    int* p;
    return i;
    return *p;
    return &i;
    return &p;

Write the example using these, sprinkling in ref, return, and scope.

If anything else appears, like class, struct, this, [], delegate, etc., more work is needed to reduce it.

Hope this helps!

On Monday, 5 July 2021 at 09:28:47 UTC, Walter Bright wrote:
>   ref int test(ref scope return int* p)
>   {
>      return *p;
>   }
[...]
> Examining Dennis' table, it has a [ref return type] and a [scope value], and so the `return` applies to the pointer type.

I think you're misreading something there.

For reference, the table:

> **Does the `return` attribute apply to the parameter's `ref` or the pointer value?**
> |                                  | `scope`   | no `scope` |
> |----------------------------------|-----------|------------|
> | `ref` return type / `ref` param  | **`ref`** | **`ref`**  |
> | value return type / `ref` param  | **value** | **`ref`**  |
> | `ref` return type / value param  | **value** | **value**  |
> | value return type / value param  | **value** | **value**  |

Your test function has a `ref` return type and a `ref` parameter, so we're looking at the first row. That row says `return` applies to the `ref` part of the parameter (with and without `scope`).

On 7/5/2021 3:01 AM, ag0aep6g wrote:
> On Monday, 5 July 2021 at 09:28:47 UTC, Walter Bright wrote:
>>   ref int test(ref scope return int* p)
>>   {
>>      return *p;
>>   }
> [...]
>> Examining Dennis' table, it has a [ref return type] and a [scope value], and so the `return` applies to the pointer type.
> 
> I think you're misreading something there.
> 
> For reference, the table:
> 
>> **Does the `return` attribute apply to the parameter's `ref` or the pointer value?**
>> |                                  | `scope`   | no `scope` |
>> |----------------------------------|-----------|------------|
>> | `ref` return type / `ref` param  | **`ref`** | **`ref`**  |
>> | value return type / `ref` param  | **value** | **`ref`**  |
>> | `ref` return type / value param  | **value** | **value**  |
>> | value return type / value param  | **value** | **value**  |
> 
> Your test function has a `ref` return type and a `ref` parameter, so we're looking at the first row. That row says `return` applies to the `ref` part of the parameter (with and without `scope`).


I think you might be right.

On Monday, 5 July 2021 at 10:44:54 UTC, Walter Bright wrote:
> On 7/5/2021 3:01 AM, ag0aep6g wrote:
>> On Monday, 5 July 2021 at 09:28:47 UTC, Walter Bright wrote:

>> Your test function has a `ref` return type and a `ref` parameter, so we're looking at the first row. That row says `return` applies to the `ref` part of the parameter (with and without `scope`).
>
>
> I think you might be right.

How the heck are us mere mortals supposed to use this stuff if you struggle to understand what it means?

On 7/5/2021 4:36 AM, claptrap wrote:
> How the heck are us mere mortals supposed to use this stuff if you struggle to understand what it means?

I make mistakes all the time. That's why D has unit tests built in, and an acceptance test suite.

One reason I like writing software is once I get it right, it stays right every time.

Actually, I find Dennis' table a tad confusing. An alternate formulation is:

---------
Consider the ambiguity of a `return ref scope` parameter. Which is it:

1. `return ref` and `scope`
2. `ref` and `return scope`

? The ambiguity is resolved by looking at the function return. If it returns
by `ref`, then it's (1), otherwise (2). This is evident in the table above.
This rule is arbitrary, precluding things like creating a `return ref` and
`return scope` for the same parameter.
----------