On Thursday, 25 November 2021 at 08:31:42 UTC, zjh wrote:

scope on a variable with a pointer type means the pointer value will not leave the scope that the variable is declared in.

There are many special cases and the documentation isn't very good.

To prevent memory corruption in @safe code when working with stack variables.

On Thursday, 25 November 2021 at 13:43:10 UTC, Dennis wrote:

Thank you for your detailed explanation. I understand roughly.
If attribute deduction is available, can the attr be omitted as much as possible?
If we can't omit an attribute, I want sugar sytax to simplify it.
Looking at funcs, attrs all around, as a lover of clean code, I can't bear it.

On Thursday, 25 November 2021 at 14:16:21 UTC, zjh wrote:

Yes

You don't have to use the attributes, it's there for @nogc @safe library code doing low-level memory management. Your applications are free to ignore it most of the time.

Also, 'clean code' is subjective. The alternative to scope parameters that you sometimes see in C libraries is a 'pointer lifetime' section in a documentation comment, which is:

• inconsistent (varies per library)
• not verified for correctness (compiler doesn't understand it)
• more verbose than a single scope keyword

I don't consider that clean.

On Thursday, 25 November 2021 at 14:40:09 UTC, Dennis wrote:

I usually use C++,C++ has no similar scope,C++ has RAII.
It's like the & of C++ versus the ref of d. & is much simpler than ref.
It would be nice if d had some symbols/sugar syntax to simplify these attributes.

On Thursday, 25 November 2021 at 15:05:55 UTC, zjh wrote:

I wonder what the reason was to choose ref instead of &. Maybe it's kinder to the parser.

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

with return ref and return scope, will there also be a return this for the case like the opIndex functions returning something with the lifetime of the containing struct? I don't quite get how it's otherwise fixing it.

On Thursday, 25 November 2021 at 15:27:20 UTC, Imperatorn wrote:

If you are new to D and don't already know C++, int& will mean nothing to you, whereas you have at least a chance of guessing what ref int means just from reading it.

On Thursday, 25 November 2021 at 15:59:41 UTC, Paul Backus wrote:

So it was more of a readability thing then

On Thursday, 25 November 2021 at 16:05:01 UTC, Imperatorn wrote:

I'm only guessing, but I suspect it's a combination of (a) readability, and (b) consistency with other storage classes (which are all words, not punctuation).

On Thursday, 25 November 2021 at 15:57:13 UTC, WebFreak001 wrote:

return this in struct member functions is return ref. Walter proposes in the bugzilla issue to allow ref after the parameter list:

struct S {
    ref int opIndex() return ref scope {

    }
}