www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feedback Thread: DIP 1034--Add a Bottom Type (reboot)--Community

reply Mike Parker <aldacron gmail.com> writes:
This is the feedback thread for the first round of Community 
Review of DIP 1034, "Add a Bottom Type (reboot)".

===================================
**THIS IS NOT A DISCUSSION THREAD**

Posts in this thread must adhere to the feedback thread rules 
outlined in the Reviewer Guidelines (and listed at the bottom of 
this post).

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

That document also provides guidelines on contributing feedback 
to a DIP review. Please read it before posting here. If you would 
like to discuss this DIP, please do so in the discussion thread:

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

==================================

You can find DIP 1034 here:

https://github.com/dlang/DIPs/blob/15081980cd393e21218da6836321ed37ebc48dd3/DIPs/DIP1034.md

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.

At the end of this review round, the DIP will be moved into the 
Post-Community Round 1 state. Significant revisions resulting 
from this review round may cause the DIP manager to require 
another round of Community Review, otherwise the DIP will be 
queued for the Final Review.

==================================
Posts in this thread that do not adhere to the following rules 
will be deleted at the DIP author's discretion:

* All posts must be a direct reply to the DIP manager's initial 
post, with only two exceptions:

     - Any commenter may reply to their own posts to retract 
feedback contained in the original post

     - The DIP author may (and is encouraged to) reply to any 
feedback solely to acknowledge the feedback with agreement or 
disagreement (preferably with supporting reasons in the latter 
case)

* Feedback must be actionable, i.e., there must be some action 
the DIP author can choose to take in response to the feedback, 
such as changing details, adding new information, or even 
retracting the proposal.

* Feedback related to the merits of the proposal rather than to 
the contents of the DIP (e.g., "I'm against this DIP.") is 
allowed in Community Review (not Final Review), but must be 
backed by supporting arguments (e.g., "I'm against this DIP 
because..."). The supporting arguments must be reasonable. 
Obviously frivolous arguments waste everyone's time.

* Feedback should be clear and concise, preferably listed as 
bullet points (those who take the time to do an in-depth review 
and provide feedback in the form of answers to the questions in 
this document will receive much gratitude). Information 
irrelevant to the DIP or is not provided in service of clarifying 
the feedback is unwelcome.
May 06
next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 6 May 2020 at 11:05:30 UTC, Mike Parker wrote:
 This is the feedback thread for the first round of Community 
 Review of DIP 1034, "Add a Bottom Type (reboot)".

 [...]
Typo in sentence "Note that rules 1 to 4 don not naturally follow from rule 0 " "do not" instead of "don not".
May 06
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 06, 2020 at 11:05:30AM +0000, Mike Parker via Digitalmars-d wrote:
[...]
 https://github.com/dlang/DIPs/blob/15081980cd393e21218da6836321ed37ebc48dd3/DIPs/DIP1034.md
[...] Under the section "Standard name", last point under "Counter arguments", second last word: "immdediately" should be spelt "immediately". T -- Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
May 06
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 06, 2020 at 11:05:30AM +0000, Mike Parker via Digitalmars-d wrote:
[...]
 https://github.com/dlang/DIPs/blob/15081980cd393e21218da6836321ed37ebc48dd3/DIPs/DIP1034.md
[...] Under "Description", "(3) Implicit conversions from noreturn to any other type are allowed.", 2nd bullet point: "respsectively" should be "respectively". T -- Lottery: tax on the stupid. -- Slashdotter
May 06
prev sibling next sibling parent Meta <jared771 gmail.com> writes:
Copying this over from the discussion thread:

noreturn x0; // compile error, must have bottom value

noreturn[1] x4; // compile error, init value is [assert(0)]

struct S {int x; noreturn y;} // definition is fine
S x5; // compile error, must have bottom value

enum E : noreturn {x = assert(0), y = assert(0)}
E e; // compile error, must have bottom value

The problem is that these require special cases in generic code. 
If these common cases cause compile errors, then every template 
will either have to have a `if (!is(T == noreturn))`, or allow 
itself to fail (possibly deep inside a stack of instantiated 
templates).

std.algorithm.group, for example, returns a Group struct, defined 
as follows:

struct Group(alias pred, R)
if (isInputRange!R)
{
     import std.typecons : Rebindable, tuple, Tuple;

     private alias E = ElementType!R;
     static if ((is(E == class) || is(E == interface)) &&
                (is(E == const) || is(E == immutable)))
     {
         private alias MutableE = Rebindable!E;
     }
     else static if (is(E : Unqual!E))
     {
         private alias MutableE = Unqual!E;
     }
     else
     {
         private alias MutableE = E;
     }

     private R _input;
     private Tuple!(MutableE, uint) _current;
     ...
}

But if R is noreturn[], then this becomes:

struct Group(alias pred, R)
if (isInputRange!R)
{
     private noreturn[] _input;
     private Tuple!(noreturn, uint) _current;
}

And because Tuple is itself a struct, and Tuple!(noreturn, uint) 
has a field of type noreturn, the following code will fail to 
compile:

[].group()

With a confusing error message inside Tuple.

I think these rules should at least be reconsidered or relaxed, 
if not removed.
May 06
prev sibling next sibling parent Q. Schroll <qs.il.paperinik gmail.com> writes:
Wherever there is "=> return" it's wrong. Drop the "return" 
keyword.
May 06
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 6 May 2020 at 11:05:30 UTC, Mike Parker wrote:
 [snip]
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. It would appear to complain about the initialization, when only the appending in the following line is illegal. A better message would be something like "Attempt to append int to noreturn[], which must always be empty". Perhaps the `noreturn` name, or whatever it will be, can be better defined at DRuntime level, like `size_t`? It'll still be standard, but can be done without without adding a keyword. It could be what Walter suggested (`alias noreturn = typeof(assert(false));`), but doing `alias noreturn = typeof(&null)` instead might be a bit easier to implement. I generally liked the rejected proposal of Walter, and I like this one even more. Good luck with the remaining work!
May 06
parent Dennis <dkorpel gmail.com> writes:
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!
May 22
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
* 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.

* Don't put a space between DIP and 1034 - this is so tag-based search works on 
it. Like #DIP1034
May 06
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
Great DIP!

In the breaking changes, it says "Any code assuming `is(typeof([]) == 
void[])` will break."

However, this is not exactly correct. If code *assumes* it is typed as 
void[], it will probably work.

For example:

void foo(void[])
{
}

foo([]); // I'm assuming it's void[], but it will still work.

The point being made is that the result of the expression `typeof([])` 
is changing. And any code that depends on that specific relationship for 
declarations will break.

I would change it to "Any code using the expression `typeof([])` for 
declarations or for template parameters might break. Any code that 
infers the type of a variable using the expression `[]` will also likely 
break."

I agree with the rest, because why would you write typeof([]) instead of 
void[]?

One possible exception:

auto x = []; // instead of typing void[] x, saving 2 characters!
x ~= ...; // now an error.

Another thing that would break -- if for some reason you have a type 
named "noreturn", and you import that from another module, there will be 
an ambiguity between object.noreturn and somemodule.noreturn.

I bet the chances of this are almost nil, but it is a possible breakage.

-Steve
May 06
parent Dennis <dkorpel gmail.com> writes:
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.
May 22
prev sibling next sibling parent reply Piotr Mitana <piotr.mitana gmail.com> writes:
I personally like the Scala's concept to name the bottom type 
"Nothing". I would therefore suggest to similarily name it 
"nothing" in D as well.

To me it sounds more natural and self-explanatory. noreturn look 
more like a keyword also due to its similarity to return keyword.

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.

Although returning nothing is a little bit less clear that 
noreturn, everyone knows void, so it has to be something 
different. And nothing[] looks much more in place then noreturn[].

So - pun intended - nothing is a thing! ;)
May 11
parent Dennis <dkorpel gmail.com> writes:
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).
May 11
prev sibling next sibling parent reply Piotr Mitana <the.mail.of.mi2 gmail.com> writes:
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);
May 16
parent Dennis <dkorpel gmail.com> writes:
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)
May 19
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
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
May 21
parent Dennis <dkorpel gmail.com> writes:
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
May 22