www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bottom type DIP 1017 and final rejection reasons?

reply aliak <something something.com> writes:
Just ran in to a situation where it'd be useful:

int run() {
   void throwError() { ... }
   if (errorCondition) { throwError(); }
   switch (blah) {
     default: throwError();
   }
}

So I looked up I DIP1017 and I think the only info I could find 
(other than the 18 page forum thread) on the rejected was "this 
proposal is not the way to go about it. He hopes to revisit the 
issue in the future." [0]

Was there any more on the details about it that is missing from 
the DIP assessment part? [1]

Cheers
- ali

[0]: 
https://forum.dlang.org/thread/msohwtbfpiucioccbcnc forum.dlang.org
[1]: 
https://github.com/dlang/DIPs/blob/4716033a8cbc2ee024bfad8942b2ff6b63521f63/DIPs/DIP1017.md#reviews
Mar 29 2020
next sibling parent reply Dennis <dkorpel gmail.com> writes:
On Sunday, 29 March 2020 at 18:18:49 UTC, aliak wrote:
 Was there any more on the details about it that is missing from 
 the DIP assessment part? [1]
Walter's DIP pitched the bottom-type as a more principled way to do a no-return attribute. However, his bottom type was designed in such a constrained way that it basically could only be used as a no-return attribute, with all the added complexity of a new type without the benefits of a principled bottom type. After the first round of community review, this critique wasn't addressed. The DIP remained basically unaltered, which spawned even more critique. I think this post by Walter is very telling: https://forum.dlang.org/post/q1obdu$6ap$1 digitalmars.com Walter knows a bottom-type is a useful concept that is better than a no-return attribute, but had a hard time putting it into words for his DIP. That's why I'm currently trying to reboot the DIP: https://github.com/dlang/DIPs/pull/172 In the reboot I'm trying to focus on other uses than defining functions that do not return. Some of the differences with the previous DIP are: - the type name is `noreturn` instead of `TBottom` - `typeof(null)` becomes `noreturn*` and `typeof([])` becomes `noreturn[]`. - variables of type `noreturn` may be declared and used just like any other type - throw-statements become expressions This enables patterns that DIP1017 did not enable, such as: ``` import std; void main() { [1].map!(x => x*2).writeln; // works [].map!(x => x*2).writeln; // error: can't instantiate map with void[] // if typeof([]) == noreturn[], the above will work too } ``` ``` void foo(int function() callback) { // ... } void main() { foo(() => throw new Exception()); // works because `noreturn function()` // is covariant with `int function()` } ``` Which hopefully shows that a bottom type is more than a no-return attribute.
Mar 29 2020
parent reply aliak <something something.com> writes:
On Sunday, 29 March 2020 at 20:49:42 UTC, Dennis wrote:
 On Sunday, 29 March 2020 at 18:18:49 UTC, aliak wrote:
 Was there any more on the details about it that is missing 
 from the DIP assessment part? [1]
Walter's DIP pitched the bottom-type as a more principled way to do a no-return attribute. However, his bottom type was designed in such a constrained way that it basically could only be used as a no-return attribute, with all the added complexity of a new type without the benefits of a principled bottom type.
Yeah I was trying to figure out what in the design was lacking but couldn't put my finger on it, hence this post.
 That's why I'm currently trying to reboot the DIP:
Yay!
 https://github.com/dlang/DIPs/pull/172

 In the reboot I'm trying to focus on other uses than defining 
 functions that do not return.

 Some of the differences with the previous DIP are:
 - the type name is `noreturn` instead of `TBottom`
Nice!
 - `typeof(null)` becomes `noreturn*` and `typeof([])` becomes 
 `noreturn[]`.
 - variables of type `noreturn` may be declared and used just 
 like any other type
 - throw-statements become expressions
Why does typeof(null) become noreturn*? And is the only use case for noreturn[] being able to map on a "void" array? Or are there other use cases? What's the use-case for being able to declare a variable of type noreturn?
 This enables patterns that DIP1017 did not enable, such as:

 ```
 import std;
 void main() {
     [1].map!(x => x*2).writeln; // works
     [].map!(x => x*2).writeln; // error: can't instantiate map 
 with void[]
     // if typeof([]) == noreturn[], the above will work too
 }
That seems cool!
 ```

 ```
 void foo(int function() callback) {
     // ...
 }

 void main() {
     foo(() => throw new Exception());
     // works because `noreturn function()`
     // is covariant with `int function()`
 }
 ```
Also cool!
Mar 30 2020
next sibling parent Johannes Loher <johannes.loher fg4f.de> writes:
Am 30.03.20 um 21:33 schrieb aliak:
 Why does typeof(null) become noreturn*>
 And is the only use case for noreturn[] being able to map on a "void"
 array? Or are there other use cases?
 
 What's the use-case for being able to declare a variable of type noreturn?
 
noreturn is the type that has no values. Hence a value of type noreturn* is a pointer that never points to a value. null is the only value a pointer can have for this to be true, i.e. the only value that noreturn* could have is null. On the other hand, all pointer types in D can hold null and it would be weird and arbitrary to change this for noreturn*. So noreturn* is the type that holds exactly one value, null. But this is also the definition of the type typeof(null). Basically, what I wrote boils down to it just being the most consistent choice. The same argument shows that making typeof([]) become noreturn[] is also the best choice. One major benefit you get from all of this is that you do not have to consider noreturn as a special case in generic code. It behaves just like any other type (well except for void, which unfortunately still needs to be special cased :().
Mar 30 2020
prev sibling parent Dennis <dkorpel gmail.com> writes:
On Monday, 30 March 2020 at 19:33:26 UTC, aliak wrote:
 Why does typeof(null) become noreturn*?
Because currently typeof(null) is a special case in the compiler that becomes redundant when you have a bottom type, since a pointer to a bottom type describes the behavior perfectly: it's a pointer that results in a program crash (a bottom value) when you dereference it.
 And is the only use case for noreturn[] being able to map on a 
 "void" array? Or are there other use cases?
map is just an example, the goal is to make any template taking a generic T[] to work on the empty array [].
 What's the use-case for being able to declare a variable of 
 type noreturn?
It is a degenerate case for generic code. What's the use case for x + 0 or x >>> 0? You wouldn't write that explicitly, but it might come up: ``` auto getBit(int i)(int n) {return (n >>> i) & 1;} unittest { assert(getBit!0(0b0010) == 0); // does 0b0010 >>> 0 assert(getBit!1(0b0010) == 1); } ``` For noreturn, you might have a generic function like: ``` void foo(T)(T[] x) { if (x.length > 0) { T firstElem = x[0]; // do stuff with firstElem } } ``` If you call foo([]), then T = noreturn and you will declare `firstElem` with that type. That's okay though, since x.length will never be larger than 0 in that case, that branch will not be taken. For more detailed rationale, please read the DIP and leave a review comment if something is unclear there.
Mar 30 2020
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On Sunday, 29 March 2020 at 18:18:49 UTC, aliak wrote:

 So I looked up I DIP1017 and I think the only info I could find 
 (other than the 18 page forum thread) on the rejected was "this 
 proposal is not the way to go about it. He hopes to revisit the 
 issue in the future." [0]

 Was there any more on the details about it that is missing from 
 the DIP assessment part? [1]
You left out the key point from your quote: "in light of the feedback in both review rounds". The feedback convinced him his was the wrong approach. Nothing more to it than that. If it had been anyone else, I wouldn't have marked the DIP as rejected. I would instead have marked it as Withdrawn, as he made the decision just as the Final Review ended and before I emailed him asking for a formal assessment. But he explicitly told me he was rejecting his own DIP.
Mar 29 2020