November 26

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

>

Would think you could write it like this:

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.

November 26

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

>

On Friday, 26 November 2021 at 02:03:41 UTC, Paul Backus wrote:

>
  • Allow return ref and return scope.
  • Forbid the return storage class from appearing in any other context.

As an occasional D(hobby) user but long-time lurker on this forum... it has been noticeable t me that D is gradually approaching C++ in complexity!

Something like this, as you hinted,...

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

... are inevitably going to be confusing to newbies.

Personally what I think would help is to somehow 'link' those keywords together that is a single entity i.e. in your example return ref and return scope becomes return-ref and return-scope.

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.

November 26

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

>

& vs ref is just one of the many things that C++ does better than D. And I'm not talking about the syntax: What is a "storage class"? And assuming this terms means anything, why would "ref" be one? In what world is a hidden pointer a "storage class"?

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

November 26

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

>

& vs ref is just one of the many things that C++ does better than D. And I'm not talking about the syntax

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

November 26

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

>

& vs ref is just one of the many things that C++ does better than D. And I'm not talking about the syntax: What is a "storage class"? And assuming this terms means anything, why would "ref" be one? In what world is a hidden pointer a "storage class"?

"&" 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.)

November 26

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

>

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

>

& vs ref is just one of the many things that C++ does better than D. And I'm not talking about the syntax: What is a "storage class"? And assuming this terms means anything, why would "ref" be one? In what world is a hidden pointer a "storage class"?

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

Ha, good one.

November 27

On Friday, 26 November 2021 at 15:42:13 UTC, Nick Treleaven 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

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.

November 27

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.

November 27

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

>

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.

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.

November 27

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

>

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

>

[...]

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.

[...]

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...

1 2 3 4 5 6 7 8