5 months ago I described an issue with ref return scope parameters:
DIP1000: 'return scope' ambiguity and why you can't make opIndex work
(N.b. in struct member functions, the this keyword is a ref parameter)

The gist of it is that the return keyword both appears in return ref and return scope, but currently the parser doesn't look at the ordering of the ref return scope keywords, so the decision is made by this rule:

• If the function returns by ref, it favors return ref, otherwise it favors return scope.

What if you want to return a slice element by ref or return a ref as a slice? Tough luck.

But wait, that rule is only what the specification says should happen. dmd actually has its own ways of choosing between return ref and return scope:

P contains indirections
I does not contain indirections
X may or may not contain indirections

Walter describes this existing behavior, as well as a proposed solution to explicitly allow the missing cases, in this bugzilla issue:
Issue 22541 - DIP1000: Resolve ambiguity of ref-return-scope parameters

What do you think of this proposal?

On Wednesday, 24 November 2021 at 23:50:13 UTC, Dennis wrote:

chinese version

On Wednesday, 24 November 2021 at 23:50:13 UTC, Dennis wrote:

Not a fan. It's a special case, and it's completely invisible to anyone who hasn't read the language spec cover-to-cover.

IMO we should only do this if we also apply it to return ref, and deprecate the return attribute in any position other than immediately before ref or scope—i.e., we essentially make return ref and return scope into "compound keywords".

Another thing I'd like to see addressed by this (or any) proposal is how it interacts with attribute inference. Do these new combinations only work when the attributes are explicitly given, rather than inferred? If so, that will mean that they cannot be used in many cases for generic code—e.g., if my template function may call a user-defined copy constructor of some generic type T, I cannot manually mark that parameter as return scope, since I do not know in advance whether the copy constructor conforms to those attributes.

On Wednesday, 24 November 2021 at 23:50:13 UTC, Dennis wrote:

The whole code is full of Unnecessary attributes(ref return scope). It's annoying to look at it. Can't it be as simple as C++?
D needs major changes. Don't tangle. There are so few users now, When will we big change without taking advantage of it?

On Thursday, 25 November 2021 at 05:02:44 UTC, Paul Backus wrote:

That is a good idea IMO. Might require a deprecation period for return !(ref / scope) though.

This raises a question: will return ref return scope become allowed?

On Thursday, 25 November 2021 at 06:29:36 UTC, zjh wrote:

What does scope mean? Why I don't understand it? What's the point?

On Thursday, 25 November 2021 at 08:20:32 UTC, Walter Bright wrote:

Lol, I obviously wasn't thinking much what the qualifier set would mean. Good point, that would be a bit like having string roundToInteger(float) in Phobos.