On Monday, 11 May 2020 at 08:48:47 UTC, Piotr Mitana wrote:
> noreturn look more like a keyword also due to its similarity to return keyword.

I don't see a problem with that. Many syntax highlighters highlight `string` like a keyword. The fact that it's technically an alias is unimportant.

> noreturn suggests clearly that the function will not return, but it is natural only for this use of the bottom type, and as the DIP states, there are more uses.

Just about the only time you actually need to spell out the bottom type is when marking a function to not return, so the name is tailored to that use case.

```
// Why write a non-template function like this?
noreturn[] getEmptyArray() {return [];}
void takesNullPointer(noreturn* ptr) {}

// This is what you actually write
noreturn panic(string msg) {assert(0, msg);}
```

> Although returning nothing is a little bit less clear that noreturn, everyone knows void, so it has to be something different.

So `nothing` is synonymous with `void`, but people are familiar with `void` so they'll figure `nothing` must refer to something different than `void`, such as `noreturn`. I have my doubts about that. I think it will be confusing, while `noreturn` is clear as day.

> And nothing[] looks much more in place then noreturn[].

If I really needed to spell it out in non-generic code, I would just write `typeof([])`, and for `noreturn*` use `typeof(null)` (which is the name the compiler uses currently).

One more thing to possibly even strengthen the rationale: bottom type will play nicely with Nullable, which would be a minor yet practical added value.

Let's have the struct:

    struct S
    {
        Nullable!int field1;
        int field2;
    }

If we want to pass a null to field1 and a value to field2, we construct it with

    S(Nullable!int.init, 4);

We need to state the underlying type explicitely. Bottom type would allow us to use

    S(Nullable!noreturn.init, 4);

BTW,

    S(Nullable!nothing.init, 4);

would look a bit better.

Furthermore, in std.typecons there could be defined a generic value:

    auto null_ = Nullable!nothing.init;

In this case we could simply write:

   S(null_, 4);

On Saturday, 16 May 2020 at 16:04:25 UTC, Piotr Mitana wrote:
> We need to state the underlying type explicitely. Bottom type would allow us to use

Thank you for the suggestion. I don't use Nullable, so I cannot relate to the situation you are describing. I can still include the example, but I need these things cleared up:
- Nullable!nothing does not implicitly convert to Nullable!T right? It would require an alias this.
- Using `null_` seems bad for readability, since it's unclear it is supposed to be `null` for the Phobos Nullable type instead of any other library nullable / optional types. Can't you define an opAssign that accepts the actual `typeof(null)`?
- D has no implicit construction so that still would not work in a constructor. Do you often find yourself wanting to initialize Nullable members to null with a constructor? Maybe you can get around to it with overloads / default parameters / factories depending on the use case, but (again) I'm not a user of Nullable so I'm not sure. An example of a struct/class with nullable members 'in the wild' would be appreciated.

(If you reply to this, don't forget to do it in the discussion thread)

On Wednesday, 6 May 2020 at 11:05:30 UTC, Mike Parker wrote:

> The review period will end at 11:59 PM ET on May 20, or when I make a post declaring it complete. Feedback posted to this thread after that point may be ignored.
>

This review round is now complete. The DIP author may respond to the feedback he is not yet addressed. Please to not reply to his responses in this thread. Further comments should be posted in the Discussion Thread:

https://forum.dlang.org/post/ooofastmtzmuylnjesyl@forum.dlang.org

On Thursday, 21 May 2020 at 14:09:20 UTC, Mike Parker wrote:
> The DIP author may respond to the feedback he is not yet addressed.

Thanks for catching the spelling / syntax errors, Patrick Schluter, H.S. Teoh and Q. Schroll!

My response to Meta can be found in the Discussion thread:
https://forum.dlang.org/post/egtqztgelwtzzryypodr@forum.dlang.org

On Wednesday, 6 May 2020 at 22:27:44 UTC, Dukc wrote:
> If the compiler will really say "element type could not be inferred from empty array" from trying to append to array of `noreturn`, it's a bad error message.

True, it was just an example of how an error message need not explicitly mention `noreturn[]` or `typeof([])` per se.

> Perhaps the `noreturn` name, or whatever it will be, can be better defined at DRuntime level, like `size_t`?

That's exactly what I'm proposing.

> I generally liked the rejected proposal of Walter, and I like this one even more. Good luck with the remaining work!

Thanks!

On Thursday, 7 May 2020 at 00:20:44 UTC, Steven Schveighoffer wrote:
> I bet the chances of this are almost nil, but it is a possible breakage.

You are right, I will revise the section accordingly.