On Friday, 26 November 2021 at 07:44:22 UTC, WebFreak001 wrote:

inout int[] getSomething(inout return this, int offset) @property { ... }

Yes, this is what I had in mind. You'd write the attributes exactly the same way you would for a non-member function.

On Friday, 26 November 2021 at 10:32:54 UTC, ShadoLight wrote:

struct S {
    ref int opIndex(return ref scope this) {
        // ...
    }
}

Yes, I also think this would be ideal. Someone in a previous thread proposed the syntax return(ref) and return(scope), which would make this possible without introducing new keywords.

However, given the stance Walter and the rest of the core team have towards breaking changes, I don't think it's likely they'd accept a proposal like this, which makes no concession at all to existing usage.

On Friday, 26 November 2021 at 09:19:45 UTC, Araq wrote:

If you don't know about C++ or D you can always ask in the learn forums.

On Friday, 26 November 2021 at 09:19:45 UTC, Araq wrote:

See this post for why C++ & is more complicated and harder to understand than D ref:
https://forum.dlang.org/post/rlssnqdidtsqjwxpmudb@forum.dlang.org

On Friday, 26 November 2021 at 09:19:45 UTC, Araq wrote:

"&" is used for many different things in C++, that is not good. Also, having two different reference types is confusing to newbies and creates trouble for generic programming.

D should try hard (and harder) to be simpler than C++, yet remain familiar to C++ programmers and equally predictable, that is the path to adoption.

If D can keep return-scope etc out of application code, then it is ok.

(Although D might need annotations that are more specific and expressive for libraries, but that is a different topic.)

On Friday, 26 November 2021 at 15:31:53 UTC, Imperatorn wrote:

Ha, good one.

On Friday, 26 November 2021 at 15:42:13 UTC, Nick Treleaven wrote:

C++ references, which look complicated, are actually simple.

And D ref, no matter what, I hate it.
A '&' is Ok,why not use it?
There are too many 'attributes', can we delete? I'm writing functions, not attrs.

On Friday, 26 November 2021 at 14:48:21 UTC, Paul Backus wrote:

inout int[] getSomething(inout return this, int offset) @property { ... }

Why copy rust.

Classes are inherently for encapsulation.

here is too ugly. I can use C++ concept to implement it.

It's so simple, you don't even have to declare this.

Rust is synonymous with ugliness. Let's not copy it.

On Saturday, 27 November 2021 at 01:17:15 UTC, zjh wrote:

inout int[] getSomething(inout return this, int offset) @property { ... }

Actually, I got the idea from Python. :)

Why do I think it's a good idea? Because it makes it really obvious which attributes apply to this and which attributes apply to the function as a whole.

For example, here's a really common error that beginning D programmers make:

struct S
{
    private int[] a;
    const int[] getArray() const { return a; }
}

If you try to compile this code, you get the following error:

Error: redundant attribute `const`

The reason for this is that in the above code, both instances of const are treated as applying to the this reference, not to the return value. The fix is to add () to the first const:

    const(int[]) getArray() const { return a; }

With an explicit this parameter, there is no room for ambiguity:

    const int[] getArray(const ref this) { return a; }

The outer const can only apply to the return value, and the inner const can only apply to the this reference.

On Saturday, 27 November 2021 at 03:41:05 UTC, Paul Backus wrote:

I have been mumbling to myself about this for a while. I think it's a fundamentally better way of expressing the attribute soup.

Can we actually switch? Not sure...