first draft Reducing the legal permutations of ref-return-scope

May 13

Walter Bright

May 13

Paolo Invernizzi

May 13

Dennis

May 13

Walter Bright

May 13

Richard (Rikki) Andrew Cattermole

May 13

Meta

May 13

Sönke Ludwig

May 13

Dukc

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?

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?

int* f(return scope int* p); // recommended
int* g(return int* p);       // currently allowed
int* h(scope return int* p); // currently allowed

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

Re: first draft Reducing the legal permutations of ref-return-scope

Posted by Dukc
in reply to Walter Bright

Permalink

Dukc

Posted in reply to Walter Bright

Permalink

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:

return without scope following always means return ref, like the spec says.
However, it is an error if the parameter isn't actually ref.

This means that

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.

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.

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.

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.

Forums