November 26, 2021

On Friday, 26 November 2021 at 00:26:35 UTC, Paul Backus wrote:

>

More seriously: this is exactly the kind of obscure "gotcha" that makes C++ so beginner-hostile, and IMO it is worth going to considerable lengths (including breaking changes) to avoid it.

Allowing breaking changes, what syntax do you think makes intuitive sense?

November 26, 2021

On Thursday, 25 November 2021 at 15:59:41 UTC, Paul Backus 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.

ref is a very simple concept. It is similar to alias. It is easy for beginners to understand, alias and nickname, who doesn't understand?
Obviously & is much simpler than ref, and even more funny, some people doubt || and && and want to replace it with and/or.
Clearly see the symbols, you understand it.
but I don't understand, Why should I use words?
Like py, full of self/and/or, it looks like an ugly design. Does anyone like it?

November 26, 2021

On Friday, 26 November 2021 at 01:05:39 UTC, zjh wrote:

>

Like py, full of self/and/or, it looks like an ugly design.

Of course, there are more funny ones, such as rust's ::, obviously C++'s ::, which is ugly. These people don't even feel it. rust is a full screen of symbols, as well as kinds of ugly abbreviations, plus kinds of disgusting redundant functions, and <<<>>> etc, which is very funny.
some language is kinds of ugliness.

Rust cannot copied everything right, which is very funny.

November 26, 2021

On Thursday, 25 November 2021 at 16:22:32 UTC, Dennis wrote:

>

used symbols such as ^% and ^$ (for example), that wouldn't make it simpler.

I've been saying, offer options, rather than the only one.(||/&&) or and|or is provided.
Both simplified symbols and complete words are provided for users to choose.
Of course, it's best to complete the attribute deduction by compiler, and the user doesn't have to write it at all.

November 26, 2021

On Friday, 26 November 2021 at 01:28:25 UTC, zjh wrote:

>

and the user doesn't have to write it at all.

Here users include library authors.

November 26, 2021

On Thursday, 25 November 2021 at 22:36:38 UTC, Walter Bright wrote:

>

I've suggested removing lazy already, with the predicted response.

lazy can be deleted completely. One can replace it with something similar to the concept of C++.
@safe @nogc pure nothrow auto ref fuck(ref int x) return ref scope;.
What can be deleted from this thing?
May be we only need to keep auto, and at most keep the @safe series, and all the rest are deducted.
It's better to delete it all. It's too ugly.
nothrow, pure, @nogc,... should all be the default.
Provide the user with a script to update the default.

November 26, 2021

On Friday, 26 November 2021 at 01:28:25 UTC, zjh wrote:

>

I've been saying, offer options, rather than the only one.(||/&&) or and|or is provided.
Both simplified symbols and complete words are provided for users to choose.
Of course, it's best to complete the attribute deduction by compiler, and the user doesn't have to write it at all.

I disagree with everything you just wrote.

  1. Adding more redundant options does not make the situation better.

  2. The point of the attribute declarations (@safe for example) is to tell the compiler what you want it to be so that it can stop and give you an error if you are wrong. Having it deduce @safe only if it is actually safe accomplishes nothing.

November 26, 2021

On Thursday, 25 November 2021 at 21:08:37 UTC, Imperatorn wrote:

>

Don't forget 😁

ref what() return;
ref the() return scope;
ref fuck() return ref scope;

auto ref what() return;
auto ref the() return scope;
auto ref fuck() return ref scope;

auto ref f1(int x)     { return x; }  // value return
auto ref f2()          { return 3; }  // value return
auto ref f3(ref int x) { return x; }  // ref return
auto ref f4(out int x) { return x; }  // ref return
auto ref f5() { static int x; return x; }

// etc

Our inout first used to solved this problem.
Now, We should use it to solve this problem again.

November 26, 2021

On Friday, 26 November 2021 at 00:31:19 UTC, Dennis wrote:

>

On Friday, 26 November 2021 at 00:26:35 UTC, Paul Backus wrote:

>

More seriously: this is exactly the kind of obscure "gotcha" that makes C++ so beginner-hostile, and IMO it is worth going to considerable lengths (including breaking changes) to avoid it.

Allowing breaking changes, what syntax do you think makes intuitive sense?

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

This means breaking code that uses syntax like ref return int a and return const ref int b, which is unambiguous and currently allowed.

The benefit of this approach is that it establishes an exact, one-to-one correspondence between syntax and semantics. Rather than having to apply a bunch of context-dependent rules to work out which attributes go where, you can just look at the code and see.

November 26, 2021

On Friday, 26 November 2021 at 02:00:38 UTC, zjh wrote:

I think,& can replace ref at all.
&,No better than ref?
why we don't use &?