www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.development - first draft Reducing the legal permutations of ref-return-scope

reply Walter Bright <newshound2 digitalmars.com> writes:
https://github.com/WalterBright/documents/blob/master/ReturnRefScope.md
May 12 2025
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Tuesday, 13 May 2025 at 04:23:05 UTC, Walter Bright wrote:

 https://github.com/WalterBright/documents/blob/master/ReturnRefScope.md


Yes please!
May 13 2025
prev sibling next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Tuesday, 13 May 2025 at 04:23:05 UTC, Walter Bright wrote:

 https://github.com/WalterBright/documents/blob/master/ReturnRefScope.md


I like the idea.


 The trouble is it's forgettable which order means what


 From what I've heard, what's most confusing is that order matters 
at all. Usually attributes are order independent: there's no 
difference between `const private  safe` and `private  safe 
const`. So `scope return` being subtly different than `return 
scope` is very surprising.


 scope return was given special meaning


*`return scope` was given special meaning


 For a parameter to be returning a ref, return ref will be 
 required


What about the implicit `ref this` parameter?

```D
struct S
{
     int* f() return; // doesn't comply with DIP text
     int* g() return ref; // syntax error currently
}
```

Also what about variations on `return scope`?
```D
int* f(return scope int* p); // recommended
int* g(return int* p);       // currently allowed
int* h(scope return int* p); // currently allowed
```
May 13 2025
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Good questions!

The idea is to eliminate ambiguity in the meaning, i.e. does a `return` apply
to 
the `scope` or to the `ref`? The ambiguity happens when the `ref`, `return` and 
`scope` are all present. Is the `return` applying to the `ref`, or the `scope`?

The resolution is when there is a `return` and a `ref` present, it must be 
written as `return ref`. When there is a `return` and a `scope` present, it
must 
be written as `return scope`. When there is a `return`, `scope`, and `ref` 
present, the `return` must immediately precede the `scope` or the `ref` it is 
meant to apply to.

There's a special case with the implicit `this` declaration:
```
struct S
{
      int* f() return; // doesn't comply with DIP text
}
```
is treated as if it were written:
```
struct S
{
      int* f(return ref S this);
}
```
The implicit `this` declaration is another source of confusion. I've been
toying 
with the idea of allowing it to be part of the parameter list.
May 13 2025
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 14/05/2025 6:57 AM, Walter Bright wrote:

 The implicit |this| declaration is another source of confusion. I've 
 been toying with the idea of allowing it to be part of the parameter list.


That would make DFA language features significantly easier to model for 
their attributes.

I've toyed with it, yes please.
May 13 2025
prev sibling parent Meta <jared771 gmail.com> writes:
On Tuesday, 13 May 2025 at 18:57:21 UTC, Walter Bright wrote:

 The implicit `this` declaration is another source of confusion. 
 I've been toying with the idea of allowing it to be part of the 
 parameter list.


That is a great idea; I've wanted it in D for a long time. We 
could even extend it so a hypothetical "explicit this" syntax 
applies to free functions as well, and enables UFCS, although 
that's probably too much of a breaking change.
May 13 2025
prev sibling next sibling parent =?UTF-8?Q?S=C3=B6nke_Ludwig?= <sludwig outerproduct.org> writes:
Am 13.05.2025 um 06:23 schrieb Walter Bright:

 https://github.com/WalterBright/documents/blob/master/ReturnRefScope.md



 This will break existing code. Hence enabling it will be behind a 


-preview=return switch, and will be the default in a future edition.

This should really also emit a deprecation warning without the preview 
switch.

Most preview switches are more or less useless as soon as external 
libraries come into play (which even includes Phobos often enough). My 
guess would be that the effect of this would probably close to zero 
before this is actually available as an edition, meaning more code that 
will fail later gets written in the meantime.
May 13 2025
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
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.
May 13 2025
prev sibling parent Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 13 May 2025 at 04:23:05 UTC, Walter Bright wrote:

 https://github.com/WalterBright/documents/blob/master/ReturnRefScope.md


I wouldn’t use a preview switch. Just issue a deprecation 
warning. The fix is reordering the attributes correctly, that is 
a simple fix that is completely local and has no semantic 
ramifications. It’s in the same spirit as requiring `auto` and 
`ref` to be adjacent.
Jun 26 2025