Am 06.05.20 um 21:07 schrieb Dennis:
> I'm considering changing it so that local noreturn variables give an error on usage instead of initialization.

Thats exactly how it should be done. From my point of view, there is no reason why declaring a variable of type noreturn should assert(0). Only accessing it should do that, at least for local variables. For example consider the following code:

auto fun(alias f)() {
    alias Type = ReturnType!f;
    Type ret;
    ret = f();
    /* do something with ret */
}

noreturn throwingFunction() {
    throw new Exception("foobar");
}

noreturn nonReturningFunction() {
    for(;;){}
}


void main() {
    try {
    	fun!(nonReturningFunction)(); // should throw Exception("foobar")
    }
    catch(Exception e) {
        // silently ignore it
    }
    fun!(nonReturningFunction)(); // should loop forever
}

I am not 100% sure about the implications for global variables, but if global variables of type noreturn are initialized explicitly, it will be a compile error because it will either be an infinite loop at compile time or throw an exception at compile time (I guess there are also some other situations, like failed asserts in betterC, but they also are compile errors).

If the variable is not initialized explicitly, I don't see any issue with it compiling. However, as soon as the variable is accessed at runtime, it must assert(0).

H.S. Theo and me had a long discussion about this stuff in one of the review threads for DIP1017 and if I remember correctly we basically agreed that this should be the behavior. The main reasoning was that this way we can avoid special cases in generic code and there is no reason not to do it that way, it's just natural. It would be a weird special case to disallow declaring variables of any type (you apply the same reasoning to void in the DIP for making void a proper unit type and I wholeheartedly agree!). However I don't remember if we considered global variables.

Aside from that: I really love this DIP, I was looking forward to it since I noticed you were working on it! It (and also the void DIP) would make D's type system feel much more natural. Thanks for your work!

Am 06.05.20 um 23:07 schrieb Johannes Loher:
> ...

After writing this, I just realized another thing: At the moment, it is required that the main function is declared using one of the following forms:

void main() { ... }
void main(string[] args) { ... }
int main() { ... }
int main(string[] args) { ... }

(https://dlang.org/spec/function.html#main)

With this DIP, might it make sense to also allow noreturn as a return type for main, just for consistency?

On 5/6/2020 4:04 AM, Mike Parker wrote:
> This is the discussion thread for the first round of Community Review of DIP 1034, "Add a Bottom Type (reboot)":
> 
> https://github.com/dlang/DIPs/blob/15081980cd393e21218da6836321ed37ebc48dd3/DIPs/DIP1034.md 

Thank you, Dennis, for a well-written DIP, and fixing #DIP1017. Maybe you can take a stab at improving the D spec prose, too?

* Mangling: prefer to stick with alpha_numeric characters for mangling. It doesn't need to be short, as I expect it to be rare

* Mention the conversion level, should be "convert".

* For comparisons, I'd use a more popular language than zig.

On Wednesday, 6 May 2020 at 21:44:17 UTC, Johannes Loher wrote:
> With this DIP, might it make sense to also allow noreturn as a return type for main, just for consistency?

I think so.

On Wednesday, 6 May 2020 at 22:26:13 UTC, Walter Bright wrote:
> Thank you, Dennis, for a well-written DIP, and fixing #DIP1017. Maybe you can take a stab at improving the D spec prose, too?

Glad to hear that. I have some other things (such as dmd bugs and prototype DIP implementations) I like to work on before looking at the D specification, but maybe I can find some time for it.

> * Mangling: prefer to stick with alpha_numeric characters for mangling. It doesn't need to be short, as I expect it to be rare

Agreed.

> * Mention the conversion level, should be "convert".

Will do.

> * For comparisons, I'd use a more popular language than zig.

While Zig is young, from what I've seen it's gaining traction. More importantly, it has overlapping goals with D (systems programming language, fix C's mistakes). That makes their design decisions more interesting to me than e.g. TypeScript or Python even though those are more popular. The only other systems programming language that I know of that has a bottom type is Rust, which I already included in the DIP. Do you have a particular language you'd like to see compared?

For reference: https://en.wikipedia.org/wiki/Bottom_type#In_programming_languages

On Thursday, 7 May 2020 at 13:45:41 UTC, Dennis wrote:
> Do you have a particular language you'd like to see compared?

Even though it's not a systems programming language, Scala could be a good example. Scala has a notoriously strict and sophisticated type system that is very much inspired by type theory: There is a top type called "Any" (which is a supertype of every other type), a bottom type called "Nothing" (which is a subtype of every other type), and void type is referred to as "Unit". (see [1] for a diagram of Scala's type system)
In Scala, "Nothing" is a non-instantiable type that is used for anything that doesn't return. Conceptually it appears to be very similar to what is envisioned in the DIP.
Here are a few "Nothing" examples:

val foo = throw new Exception();  // compiles; `foo` will have type `Nothing`
                                  // `foo` will never be assigned to

def bar(n: Int): String = {
    n match {
        case 1 => "one"
        case 2 => "two"
        // note that even though the return type is `String`, the following is
        // valid because `Nothing` is a subtype of `String` (and every other type)
        case _ => throw new Exception()  // `case _` is equivalent to `default` in D
        // alternatively, `assert(false)` would give a similar result
        // `case _ => Nothing` would NOT work because `Nothing` is non-instantiable
    }
}

val baz = () => throw new Exception()
// type of baz is Function0[Nothing]
// meaning: a nullary function that returns `Nothing` (i.e. doesn't return at all)

As one would expect, the Scala standard library uses "Nothing" as the return type of its exit and error functions: see [2] (notice the hack in exit: Since Java's System.exit returns void -- or "Unit" in Scala lingo -- the exit function throws, just so its return type can be "Nothing")

[1] https://docs.scala-lang.org/resources/images/tour/unified-types-diagram.svg
[2] https://github.com/scala/scala/blob/2.13.x/src/library/scala/sys/package.scala#L22

On 5/7/2020 6:45 AM, Dennis wrote:
>> * For comparisons, I'd use a more popular language than zig.
> 
> While Zig is young, from what I've seen it's gaining traction. More importantly, it has overlapping goals with D (systems programming language, fix C's mistakes). That makes their design decisions more interesting to me than e.g. TypeScript or Python even though those are more popular. The only other systems programming language that I know of that has a bottom type is Rust, which I already included in the DIP. Do you have a particular language you'd like to see compared?
> 
> For reference: https://en.wikipedia.org/wiki/Bottom_type#In_programming_languages

Actually, I think that link would be enough.

On Wednesday, 6 May 2020 at 11:04:06 UTC, Mike Parker wrote:
> This is the discussion thread for the first round of Community Review of DIP 1034, "Add a Bottom Type (reboot)":
>

Thanks for this Dennis!  You're doing the Lord's work :)

On Wednesday, 6 May 2020 at 11:04:06 UTC, Mike Parker wrote:
> [..]

I think it's good to consider how UFCS would interact with the bottom type. I just saw that Dart decided that it should not be possible to have extensions (which are similar to UFCS in D) on Never (more precisely that extensions would not apply to Never):

https://github.com/dart-lang/language/pull/1003/files#diff-dcbb29985b096645570ae14645f65d53R713

> For the purposes of extension method resolution, the type `Never` is considered to implement all members, and hence no extension may apply to an expression of type `Never`.