This is the discussion thread for the Final Review of DIP 1034, "Add a Bottom Type (reboot)":

https://github.com/dlang/DIPs/blob/b5bf9c4bed7afdae3bea1485093dbf2431bf72c7/DIPs/DIP1034.md

The review period will end at 11:59 PM ET on October 6, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

On Tuesday, 22 September 2020 at 12:14:50 UTC, Mike Parker wrote:

>
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post.

The feedback thread is here:

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

On Tuesday, 22 September 2020 at 12:14:50 UTC, Mike Parker wrote:
> This is the discussion thread for the Final Review of DIP 1034, "Add a Bottom Type (reboot)":
>
> https://github.com/dlang/DIPs/blob/b5bf9c4bed7afdae3bea1485093dbf2431bf72c7/DIPs/DIP1034.md

****PLEASE NOTE****
I apologize. The above is the wrong link. The correct link is here:

https://github.com/dlang/DIPs/blob/d492715d3c7ba2cee898930d261ab113c0a66ef9/DIPs/DIP1034.md

On Tuesday, 22 September 2020 at 12:14:50 UTC, Mike Parker wrote:
> This is the discussion thread for the Final Review of DIP 1034, "Add a Bottom Type (reboot)":
>
> https://github.com/dlang/DIPs/blob/b5bf9c4bed7afdae3bea1485093dbf2431bf72c7/DIPs/DIP1034.md
>
> The review period will end at 11:59 PM ET on October 6, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.
>
> Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.
>
> However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> And my blog post on the difference between the Discussion and Feedback threads:
>
> https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/
>
> Please stay on topic here. I will delete posts that are completely off-topic.

I have one (very) general comment. Since we are talking about the halting problem, completeness etc. Since time is in essence the problem, would it be possible to annotate a function with a timeout (physical or virtual time) which leads to the bottom type if exceeded? This could in theory be very useful.

On Tuesday, 22 September 2020 at 12:44:14 UTC, Imperatorn wrote:
> I have one (very) general comment. Since we are talking about the halting problem, completeness etc. Since time is in essence the problem, would it be possible to annotate a function with a timeout (physical or virtual time) which leads to the bottom type if exceeded? This could in theory be very useful.

I have trouble picturing what you're suggesting.
You mean something like this?

```
import std;
@timeout(500.msecs) int computeSum(int[] arr) {
    int result = 0;
    foreach(v; arr) result += v;
    return result;
}

void main(string[] args) {
    int result = computeSum(args[1..$].map!(to!int).array);

    // the program will now crash with `assert(0)` if computeSum
    // did not complete in under half a second?

    writeln(result); // otherwise print result
}
```

I don't see when that's ever useful or why you need a bottom type to do that.

Continuing discussion from feedback thread:

On 9/22/20 11:08 AM, Dennis wrote:
> On Tuesday, 22 September 2020 at 14:16:19 UTC, Steven Schveighoffer wrote:
>> ```
>> int x;
>> int bar();
>> auto foo() {
>>     cast(noreturn) (x = bar()); // same as {x = bar(); assert(0);}
>> }
>> ```
>>
>> This is odd, and I'm not understanding the reason for the cast if you aren't assigning.
> 
> This code has no reason, it's just an example of the rewrite that happens with `cast(noreturn)`. It could actually be useful in generic code, or when you are using a function that is noreturn but does not have the correct return type.
> ```
> // someone else's code
> void panic(string msg);
> 
> // your code:
> auto f = () => cast(noreturn) panic("error");
> ```

The difference in the second example (which makes sense to me) is that you are returning the noreturn value.

If the first example said:

```
return cast(noreturn) (x = bar());
```

Then I understand. I thought the code was making an explicit point that not using the casted result still results in an assert(0).

> 
>> Also, earlier you say that you can declare a noreturn variable, but as long as you don't use it, you don't generate the assert 0. Is this example a contradiction of that?
> 
> I don't think so, the example does not declare a local variable. I could rewrite it to this:
> 
> ```
> import std;
> int x;
> int bar();
> auto foo() {
>      noreturn y; // no assert here yet
>      writeln("this will get printed");
>      y = cast(noreturn) (x = bar());
>      // here it results in assert(0)
> }
> ```
> 
> The reason for this is argued by Johannes Loher here:
> https://forum.dlang.org/post/r8v8tt$14fk$1@digitalmars.com
> 
>> ```
>> /* 6 */ !(is(T == function)) || is(noreturn* : T)
>> /* 7 */ !(is(T == delegate)) || is(noreturn* : T)
>> ```
>>
>> What are these trying to say? I think these rules need some clarification or rewriting
> 
> In formal logic, "(not p) or q" is equivalent to "if p then q",

OK, I see what you are trying to do. The parentheses make it hard to see what it's trying to say. A comment or more specific explanation may help.

BTW, is(T == function) only works on actual function types, not function pointers. I think you meant function pointers.

-Steve

On Tuesday, 22 September 2020 at 15:46:39 UTC, Steven Schveighoffer wrote:
>
> BTW, is(T == function) only works on actual function types, not function pointers. I think you meant function pointers.
>
> -Steve

Pointing this detail out kindly is a good behavior. In the python-ideas mailing list, too often the attitude is "Your one detail is wrong therefore I will ignore and reject your entire proposal."

On Tuesday, 22 September 2020 at 15:22:21 UTC, Dennis wrote:
> On Tuesday, 22 September 2020 at 12:44:14 UTC, Imperatorn wrote:
>> I have one (very) general comment. Since we are talking about the halting problem, completeness etc. Since time is in essence the problem, would it be possible to annotate a function with a timeout (physical or virtual time) which leads to the bottom type if exceeded? This could in theory be very useful.
>
> I have trouble picturing what you're suggesting.
> You mean something like this?
>
> ```
> import std;
> @timeout(500.msecs) int computeSum(int[] arr) {
>     int result = 0;
>     foreach(v; arr) result += v;
>     return result;
> }
>
> void main(string[] args) {
>     int result = computeSum(args[1..$].map!(to!int).array);
>
>     // the program will now crash with `assert(0)` if computeSum
>     // did not complete in under half a second?
>
>     writeln(result); // otherwise print result
> }
> ```
>
> I don't see when that's ever useful or why you need a bottom type to do that.

Well, what about determinism, reasoning about halting, real-time contexts, time sharing, functional safety, async/await control, FSM constraints, resource management,..., etc

Well, strictly not bottom type, but it could be related,like (pseudo-code) @timeout(500.msecs, doSomething(), return something)

On Tuesday, 22 September 2020 at 17:46:07 UTC, Imperatorn wrote:
> Well, what about determinism, reasoning about halting, real-time contexts, time sharing, functional safety, async/await control, FSM constraints, resource management,..., etc

I get why asynchronous execution and time-outs are useful, but why do you want a time-out that results in the entire program crashing? To me it looks like you'd want a function returning a Nullable!T which is null in case of a time out, instead of a `noreturn` function which is guaranteed to always fail.

> Well, strictly not bottom type, but it could be related,like (pseudo-code) @timeout(500.msecs, doSomething(), return something)

So does your proposal fit in this DIP?

On Tuesday, 22 September 2020 at 21:13:04 UTC, Dennis wrote:
> On Tuesday, 22 September 2020 at 17:46:07 UTC, Imperatorn wrote:
>> Well, what about determinism, reasoning about halting, real-time contexts, time sharing, functional safety, async/await control, FSM constraints, resource management,..., etc
>
> I get why asynchronous execution and time-outs are useful, but why do you want a time-out that results in the entire program crashing? To me it looks like you'd want a function returning a Nullable!T which is null in case of a time out, instead of a `noreturn` function which is guaranteed to always fail.
>
>> Well, strictly not bottom type, but it could be related,like (pseudo-code) @timeout(500.msecs, doSomething(), return something)
>
> So does your proposal fit in this DIP?

Hmm... I guess it should be a new DIP. It's related to this, but not enough.