July 21, 2021
On 7/21/2021 7:12 PM, zjh wrote:
> I am also `experienced ` C++ Programmer,why I don't hurt from it?

There are many ways to experience C++.

Anyhow, the reason that default constructors are not allowed is so that default constructing an object will always succeed. This makes for a significant reduction in complexity. For example, default construction then becomes pure and nothrow.

Not everyone agrees, of course.
July 21, 2021
On 7/21/2021 8:47 PM, Mathias LANG wrote:
> What I meant was that instead of recommending our users to use `switch (value) with `(EnumType)`, we could just make it the default since it's the common case with enums. Unless we think that requiring the type of the enum be spelt out is better.
> 
> It could add to the long list of those usability enhancements that are a hallmark of D (like `_` in number literals). I personally don't mind the verbosity, but I heard this complaint a few times over the years.

Ok, I see what you mean. If it was restricted to the case value expressions, there is merit to the idea. But suppose:

    enum A = 3, B = 4;
    switch (x) {
      case A: ...
      case B: ...
    }

there isn't much of a clue that `case A` is not `case 3`, which matters more and more the larger the program gets.

One thing I've learned with D is that programmers often have mental models of how symbol lookup is done that diverge substantially from how it actually works, and I've never been able to communicate how things actually work to them. Putting a special case in like this is pretty risky.
July 21, 2021
I can see the Scott Meyers slide on "Quirks Of D" already:

"You would think that this would be `case 3`. But noooo, you'd be wrong!"
July 22, 2021

On Thursday, 22 July 2021 at 04:37:43 UTC, Walter Bright wrote:

>

there isn't much of a clue that case A is not case 3, which matters more and more the larger the program gets.

That's a very good point, I didn't think about local enum when trying to come up with corner cases. And IMO that's a dealbreaker for this idea, since local enums for case statements aren't that rare, at least in the code I've worked with.

July 22, 2021

On Thursday, 22 July 2021 at 04:26:45 UTC, Walter Bright wrote:

>

On 7/21/2021 7:12 PM, zjh wrote:

>

I am also experienced C++ Programmer,why I don't hurt from it?

As a plain user, I hope to have the same convenience as C++.
I know you are very professional. But, the development of the D language,Don't you need a lot of primary users?
IMO, As a language leader, You should provide users with a variety of choices like C++.
When users feel great, they will naturally let their friends to use D.
C++'s advantage is although It don't do well, but It provide you basic facilities.
D,the biggest weakness is ecology. Ecology is made up of users. A large number of users may not be as professional as you.
So I think d should work hard on small details to gain users.
I've been saying that the biggest advantage of D is better c++, which can attract C++ programmers.
C++ programmer, can help D in two places, one is to bring the user, the other is to bring the library which brings the user.
Therefore, D should pay more attention to the experience of the C++ man, rather than the average force, resulting in nothing.

July 22, 2021
On 22/07/2021 4:37 PM, Walter Bright wrote:
> One thing I've learned with D is that programmers often have mental models of how symbol lookup is done that diverge substantially from how it actually works, and I've never been able to communicate how things actually work to them.

If you can't describe it using words, use code instead.

That logic in the compiler could be a great example of your desire to distill it down. If the logic and data is encapsulated well, it could look very pseudo-code-ish!
July 22, 2021

On Thursday, 22 July 2021 at 04:37:43 UTC, Walter Bright wrote:

>

On 7/21/2021 8:47 PM, Mathias LANG wrote:

>

What I meant was that instead of recommending our users to use
and I've never been
able to communicate how things actually work to them.

Because the forum can not label the post, and We didn't sort out the answers and posts.
So, you answer it over and over again.
And You will be asked the same question again and again.

We need to mobilize the community to submit what they think excellent and useful answers and label them for classify.
And specially put in a section of the forum like Good Answers and Posts,
And should add label function to the posts and answers for the forum.

July 22, 2021

On Thursday, 22 July 2021 at 06:12:43 UTC, zjh wrote:

>

On Thursday, 22 July 2021 at 04:26:45 UTC, Walter Bright wrote:

>

On 7/21/2021 7:12 PM, zjh wrote:

>

I am also experienced C++ Programmer,why I don't hurt from it?

Primary users increase, promote the increase of lib writers, increase users, and increase lib writers.
Why more users, more people write library, because more people use, more sense of achievement. More libraries, naturally increase users.
So the more users, the better.
The more users, the more errors found, the more errors corrected, the better experience, and the more users.

In this way, it also constitutes a positive cycle.
Therefore, we must pay attention to primary users.

July 22, 2021
On Thursday, 22 July 2021 at 04:37:43 UTC, Walter Bright wrote:
> On 7/21/2021 8:47 PM, Mathias LANG wrote:
>> What I meant was that instead of recommending our users to use `switch (value) with `(EnumType)`, we could just make it the default since it's the common case with enums. Unless we think that requiring the type of the enum be spelt out is better.
>> 
>> It could add to the long list of those usability enhancements that are a hallmark of D (like `_` in number literals). I personally don't mind the verbosity, but I heard this complaint a few times over the years.
>
> Ok, I see what you mean. If it was restricted to the case value expressions, there is merit to the idea. But suppose:
>
>     enum A = 3, B = 4;
>     switch (x) {
>       case A: ...
>       case B: ...
>     }
>
> there isn't much of a clue that `case A` is not `case 3`, which matters more and more the larger the program gets.

This case is comparable to variable shadowing and should then be handled the same way.
btw, as of now, what will happen in the case

```
enum ENUM { A, B, C }
    ENUM x = ENUM.A;
    enum A = 3, B = 4;

    switch (x) with (ENUM) {
       case A: writeln("case A=", cast(int)A);break;
       case B: writeln("case B=", cast(int)B);break;
       default:writeln("whatever x=", cast(int)x);
    }
```
https://run.dlang.io/is/7Ar7dQ

it will use the values defined in ENUM and ignore the `enum A` and `enum B` values.
The compiler should at least warn of the ambiguity if the `with(ENUM)` is removed.


> One thing I've learned with D is that programmers often have mental models of how symbol lookup is done that diverge substantially from how it actually works, and I've never been able to communicate how things actually work to them. Putting a special case in like this is pretty risky.


July 22, 2021

On Thursday, 22 July 2021 at 04:37:43 UTC, Walter Bright wrote:

>

On 7/21/2021 8:47 PM, Mathias LANG wrote:

>

What I meant was that instead of recommending our users to use switch (value) with (EnumType)`, we could just make it the default since it's the common case with enums. Unless we think that requiring the type of the enum be spelt out is better.

It could add to the long list of those usability enhancements that are a hallmark of D (like _ in number literals). I personally don't mind the verbosity, but I heard this complaint a few times over the years.

Ok, I see what you mean. If it was restricted to the case value expressions, there is merit to the idea. But suppose:

enum A = 3, B = 4;
switch (x) {
  case A: ...
  case B: ...
}

there isn't much of a clue that case A is not case 3, which matters more and more the larger the program gets.
Currently, that's what happens

```
	enum ENUM { A, B, C }
    ENUM x = ENUM.A;
    enum A = 3, B = 4;

    switch (x) /*with (ENUM)*/ {
       case A: writeln("case A=", cast(int)A);break;
       case B: writeln("case B=", cast(int)B);break;
       default:writeln("whatever x=", cast(int)x);
    }
```
onlineapp.d(11): Error: cannot implicitly convert expression `3` of type `int` to `ENUM`
onlineapp.d(12): Error: cannot implicitly convert expression `4` of type `int` to `ENUM`
onlineapp.d(12): Error: duplicate `case 4` in `switch` statement

https://run.dlang.io/is/a12yVL

The compiler will already do the right thing as it cannot convert the enum A and enum B to the type of x.

>

One thing I've learned with D is that programmers often have mental models of how symbol lookup is done that diverge substantially from how it actually works, and I've never been able to communicate how things actually work to them. Putting a special case in like this is pretty risky.