digitalmars.D - DIP 1017--Add Bottom Type--Community Review Round 1
- Mike Parker (14/14) Aug 08 2018 This is the feedback thread for the first round of Community
- Nicholas Wilson (46/60) Aug 08 2018 All of my points made in the draft review still stand, i.e. that
- Andrea Fontana (5/11) Aug 09 2018 Let's say we need to implement an interface with a int func();
- w0rp (9/21) Aug 09 2018 It will work, and why it will work requires some understanding of
- Andrea Fontana (6/31) Aug 09 2018 is(T == int) will work with T==tbottom too?
- Petar Kirov [ZombineDev] (9/42) Aug 10 2018 `is(T == U)` evaluates to true iff `T` is exactly `U`. `is(T :
- Andrea Fontana (12/20) Aug 10 2018 So if I need to write something like:
- Petar Kirov [ZombineDev] (2/25) Aug 10 2018 No. That's the point - you don't have to change anything.
- Dukc (2/6) Aug 10 2018 One example comes to mind: is(typeof(null) == typeof(assert(0))).
- Dukc (2/4) Aug 10 2018 meant is(typeof(*null) == typeof(assert(0)))
- Nicholas Wilson (5/10) Aug 10 2018 How is that a good thing??? Also that is not specified in the
- Dukc (10/15) Aug 10 2018 Granted, an example like that should be described so we know
- Stefan Koch (4/21) Aug 10 2018 No that cant be happing, retuning null is still returning
- Timon Gehr (6/13) Aug 10 2018 I think you misunderstood. His point was that this could work:
- Stefan Koch (3/17) Aug 10 2018 Ah yes ... Thanks!
- Nicholas Wilson (3/10) Aug 11 2018 Of what _practical use_ is that?
- Dukc (7/17) Aug 13 2018 I have no doubt you know more about compiler internals than me so
- Uknown (5/5) Aug 08 2018 I would like to point out that C++ does this with attributes
- Dominikus Dittes Scherkl (9/14) Aug 09 2018 The DIP mentions that, (e.g. I also don't like the syntax
- Stefan Koch (26/29) Aug 09 2018 Regarding the rationale:
- Nicholas Wilson (11/27) Aug 09 2018 I presume Walter is talking about considering all branches that
- Kagamin (7/10) Aug 09 2018 Maybe total code size.
- 12345swordy (4/7) Aug 09 2018 How does this DIP interact with constructors and deconstructors
- bachmeier (3/5) Aug 09 2018 I hope there is a better name than Tbottom. A name like that is
- Stefan Koch (4/9) Aug 09 2018 according to the DIP, the name can be chosen arbitrarily as the
- bachmeier (3/9) Aug 09 2018 Okay. That's a lot worse. A type for a function that returns
- Gary Willoughby (4/9) Aug 09 2018 `bottom_t` or `never_t` are much better but perhaps this should
- bachmeier (2/4) Aug 09 2018 Yes, it should.
- w0rp (3/3) Aug 09 2018 A better name for this type is `never`, which is the name of the
- docandrew (3/6) Aug 10 2018 +1 for "never" - it's descriptive and readable.
- Arun Chandrasekaran (2/8) Aug 10 2018 +1 for "never"
- Dukc (6/12) Aug 11 2018 And brings us closer to Rust, which is a good thing.
- Timon Gehr (9/29) Aug 09 2018 Copy-paste of my comment on the DIP pull request:
This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": https://github.com/dlang/DIPs/blob/8274b0f600075e4553b41c31f4b77be2d917bb40/DIPs/DIP1017.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 24, or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the Final Review and Formal Assessment by the language maintainers. Please familiarize yourself with the documentation for the Community Review before participating. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review Thanks in advance to all who participate.
Aug 08 2018
On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote:This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": https://github.com/dlang/DIPs/blob/8274b0f600075e4553b41c31f4b77be2d917bb40/DIPs/DIP1017.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 24, or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the Final Review and Formal Assessment by the language maintainers. Please familiarize yourself with the documentation for the Community Review before participating. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review Thanks in advance to all who participate.All of my points made in the draft review still stand, i.e. that this should be an attribute or pragma. Note that this feature is already supported by LDC as an attribute. The benefit that this DIP provides are: "documentation" (rationale point 2) and optimisation (rationale points 1 & 4). The claim made by Point 3 is dubious and unsubstantiated at best. Rationale point 2 comes in the form of rendered documentation and the source code. Rendered documentation, regardless of the form used should be able to convey that a function does not return. Reading the source it should be easily determinable that a function does not return, use of an suitably named attribute or pragma (i.e. pragma (noreturn) or noreturn) makes it immediately obvious. Returning a type named "Tbottom" absolutely does not, "never_t" as suggested in the draft review is better but is not strictly better than an attribute or pragma but, IMO is still worse. The optimisation benefits provided by dead code elimination may be significant, but again this information is equally well conveyed to the compiler by an attribute or pragma. The hardcoded list of symbols, will provide the vast majority of those gains so extending this to user code will provide very marginal benefit, especially with a aggressively optimising compiler (e.g. LDC, GDC) that will propagate that information anyway. The downsides of this DIP are the breaking changes and unneeded complexity. Generic code that checks `is(T==void)` or `is(ReturnType!F == void)` will break, as will code that uses the return value of a function that happens to be inferred to return no type, use of the ternary ?: will now no longer always be the common type of the second and third operands. The complexity will manifest itself as making error messages more confusing, making the learning curve steeper than it needs to be and the implementation. The DIP makes the claim that: * "[ noreturn] has the awkward result of a function specifying it has a return type T, but never returns that type". When it is deliberate (such as annotating a fatal error function) the is almost exclusively `void` (I know of no examples to the contrary). * "[With noreturn] other potential uses of a bottom type will not be expressible". What other? Documentation and optimisation definitely can be, the are in LDC since a long time, there are no other substantiated benefits listed in the DIP. If this DIP were to make the claim that type inference and propagation would catch bugs, then perhaps it would make more sense than an attribute or pragma, but it would have to be convincing that resulting code breakage would be worth it.
Aug 08 2018
On Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote:The DIP makes the claim that: * "[ noreturn] has the awkward result of a function specifying it has a return type T, but never returns that type". When it is deliberate (such as annotating a fatal error function) the is almost exclusively `void` (I know of no examples to the contrary).Let's say we need to implement an interface with a int func(); member. We can mark it with noreturn but we can't use TBottom return type: we're going to break interface implementation. Andrea
Aug 09 2018
On Thursday, 9 August 2018 at 10:37:36 UTC, Andrea Fontana wrote:On Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote:It will work, and why it will work requires some understanding of bottom types. You can define the function as `TBottom func()` and it should work, because `TBottom` is a subtype of `int`. In the same way you can implement `ParentClass func()` as `SubClass func()`, because `SubClass` is a subtype of `ParentClass`. Similarly, you can assign values of `TBottom` to `int`, because `TBottom` is a subtype of all types, but you cannot assign `int` to `TBottom`, because `int` is not a subtype of `TBottom`.The DIP makes the claim that: * "[ noreturn] has the awkward result of a function specifying it has a return type T, but never returns that type". When it is deliberate (such as annotating a fatal error function) the is almost exclusively `void` (I know of no examples to the contrary).Let's say we need to implement an interface with a int func(); member. We can mark it with noreturn but we can't use TBottom return type: we're going to break interface implementation. Andrea
Aug 09 2018
On Thursday, 9 August 2018 at 15:56:31 UTC, w0rp wrote:On Thursday, 9 August 2018 at 10:37:36 UTC, Andrea Fontana wrote:is(T == int) will work with T==tbottom too? is(T:int) ? I feel that all this things are going to complicate implementation and add corner cases, but maybe I'm wrong... AndreaOn Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote:It will work, and why it will work requires some understanding of bottom types. You can define the function as `TBottom func()` and it should work, because `TBottom` is a subtype of `int`. In the same way you can implement `ParentClass func()` as `SubClass func()`, because `SubClass` is a subtype of `ParentClass`. Similarly, you can assign values of `TBottom` to `int`, because `TBottom` is a subtype of all types, but you cannot assign `int` to `TBottom`, because `int` is not a subtype of `TBottom`.The DIP makes the claim that: * "[ noreturn] has the awkward result of a function specifying it has a return type T, but never returns that type". When it is deliberate (such as annotating a fatal error function) the is almost exclusively `void` (I know of no examples to the contrary).Let's say we need to implement an interface with a int func(); member. We can mark it with noreturn but we can't use TBottom return type: we're going to break interface implementation. Andrea
Aug 09 2018
On Friday, 10 August 2018 at 06:44:20 UTC, Andrea Fontana wrote:On Thursday, 9 August 2018 at 15:56:31 UTC, w0rp wrote:`is(T == U)` evaluates to true iff `T` is exactly `U`. `is(T : U)` tests if `T` is a subtype of (can be implicitly converted to) `U` [0]. So we have: `is(typeof(assert(0)) == T)` is false, unless `T` is `typeof(assert(0))` `is(typeof(assert(0)) : T)` is always true (as bottom is implicitly convertible to any other type, including itself). [0]: https://dlang.org/spec/expression#is_expressionOn Thursday, 9 August 2018 at 10:37:36 UTC, Andrea Fontana wrote:is(T == int) will work with T==tbottom too? is(T:int) ? I feel that all this things are going to complicate implementation and add corner cases, but maybe I'm wrong... AndreaOn Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote:It will work, and why it will work requires some understanding of bottom types. You can define the function as `TBottom func()` and it should work, because `TBottom` is a subtype of `int`. In the same way you can implement `ParentClass func()` as `SubClass func()`, because `SubClass` is a subtype of `ParentClass`. Similarly, you can assign values of `TBottom` to `int`, because `TBottom` is a subtype of all types, but you cannot assign `int` to `TBottom`, because `int` is not a subtype of `TBottom`.The DIP makes the claim that: * "[ noreturn] has the awkward result of a function specifying it has a return type T, but never returns that type". When it is deliberate (such as annotating a fatal error function) the is almost exclusively `void` (I know of no examples to the contrary).Let's say we need to implement an interface with a int func(); member. We can mark it with noreturn but we can't use TBottom return type: we're going to break interface implementation. Andrea
Aug 10 2018
On Friday, 10 August 2018 at 07:01:09 UTC, Petar Kirov [ZombineDev] wrote:`is(T == U)` evaluates to true iff `T` is exactly `U`. `is(T : U)` tests if `T` is a subtype of (can be implicitly converted to) `U` [0]. So we have: `is(typeof(assert(0)) == T)` is false, unless `T` is `typeof(assert(0))` `is(typeof(assert(0)) : T)` is always true (as bottom is implicitly convertible to any other type, including itself). [0]: https://dlang.org/spec/expression#is_expressionSo if I need to write something like: void callback(alias T)() if(is(ReturnType!T == int)) { } I have to change it to: void callback(alias T)() if(is(ReturnType!T == int) || is(ReturnType!T == typeof(assert(0))) { } ?
Aug 10 2018
On Friday, 10 August 2018 at 07:19:02 UTC, Andrea Fontana wrote:On Friday, 10 August 2018 at 07:01:09 UTC, Petar Kirov [ZombineDev] wrote:No. That's the point - you don't have to change anything.`is(T == U)` evaluates to true iff `T` is exactly `U`. `is(T : U)` tests if `T` is a subtype of (can be implicitly converted to) `U` [0]. So we have: `is(typeof(assert(0)) == T)` is false, unless `T` is `typeof(assert(0))` `is(typeof(assert(0)) : T)` is always true (as bottom is implicitly convertible to any other type, including itself). [0]: https://dlang.org/spec/expression#is_expressionSo if I need to write something like: void callback(alias T)() if(is(ReturnType!T == int)) { } I have to change it to: void callback(alias T)() if(is(ReturnType!T == int) || is(ReturnType!T == typeof(assert(0))) { } ?
Aug 10 2018
On Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote:* "[With noreturn] other potential uses of a bottom type will not be expressible". What other? Documentation and optimisation definitely can be, the are in LDC since a long time, there are no other substantiated benefits listed in the DIP.One example comes to mind: is(typeof(null) == typeof(assert(0))).
Aug 10 2018
On Friday, 10 August 2018 at 11:28:38 UTC, Dukc wrote:One example comes to mind: is(typeof(null) == typeof(assert(0))).meant is(typeof(*null) == typeof(assert(0)))
Aug 10 2018
On Friday, 10 August 2018 at 11:31:02 UTC, Dukc wrote:On Friday, 10 August 2018 at 11:28:38 UTC, Dukc wrote:How is that a good thing??? Also that is not specified in the dip. I would expect that to fail because both will produce error nodes in the AST, only assert(0) is considered special under this DIP.One example comes to mind: is(typeof(null) == typeof(assert(0))).meant is(typeof(*null) == typeof(assert(0)))
Aug 10 2018
On Friday, 10 August 2018 at 12:42:37 UTC, Nicholas Wilson wrote:Granted, an example like that should be described so we know better what he means with the possible future uses. The benefit would be that null can be a regular pointer constant (enum null = typeof(&assert(false)).init) instead of a symbol with special meaning. I'd think it makes compiler rules less complex. Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.meant is(typeof(*null) == typeof(assert(0)))How is that a good thing??? Also that is not specified in the dip. I would expect that to fail because both will produce error nodes in the AST, only assert(0) is considered special under this DIP.
Aug 10 2018
On Friday, 10 August 2018 at 13:15:46 UTC, Dukc wrote:On Friday, 10 August 2018 at 12:42:37 UTC, Nicholas Wilson wrote:No that cant be happing, retuning null is still returning something. as opposed to not returning.Granted, an example like that should be described so we know better what he means with the possible future uses. The benefit would be that null can be a regular pointer constant (enum null = typeof(&assert(false)).init) instead of a symbol with special meaning. I'd think it makes compiler rules less complex. Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.meant is(typeof(*null) == typeof(assert(0)))How is that a good thing??? Also that is not specified in the dip. I would expect that to fail because both will produce error nodes in the AST, only assert(0) is considered special under this DIP.
Aug 10 2018
On 11.08.2018 01:40, Stefan Koch wrote:I think you misunderstood. His point was that this could work: void foo(T)(T* ptr){} void main(){ foo(null); }Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.No that cant be happing, retuning null is still returning something. as opposed to not returning.
Aug 10 2018
On Saturday, 11 August 2018 at 00:01:34 UTC, Timon Gehr wrote:On 11.08.2018 01:40, Stefan Koch wrote:Ah yes ... Thanks! (also I should not ignore the grammar/spell checker)I think you misunderstood. His point was that this could work: void foo(T)(T* ptr){} void main(){ foo(null); }Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.No that cant be happing, retuning null is still returning something. as opposed to not returning.
Aug 10 2018
On Friday, 10 August 2018 at 13:15:46 UTC, Dukc wrote:The benefit would be that null can be a regular pointer constant (enum null = typeof(&assert(false)).init) instead of a symbol with special meaning. I'd think it makes compiler rules less complex.I disagree.Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.Of what _practical use_ is that?
Aug 11 2018
On Saturday, 11 August 2018 at 10:04:14 UTC, Nicholas Wilson wrote:On Friday, 10 August 2018 at 13:15:46 UTC, Dukc wrote:I have no doubt you know more about compiler internals than me so not arguing about that.The benefit would be that null can be a regular pointer constant (enum null = typeof(&assert(false)).init) instead of a symbol with special meaning. I'd think it makes compiler rules less complex.I disagree.Tried to come up with an example but it would be so far-fetched that it won't be a reason in itself to add a new feature. I have to start to think longer before I post.Another advantage is that you could pass null as an argument for a function template which wants to know it's element type (but of course not instantiate it) like any other pointer.Of what _practical use_ is that?
Aug 13 2018
I would like to point out that C++ does this with attributes instead[0]. If this was an attribute instead (like ` noreturn`), it would simplify interfacing with C++. It would also avoid the breaking change. [0]: eel.is/c++draft/DCL.attral.noreturn
Aug 08 2018
On Thursday, 9 August 2018 at 04:16:45 UTC, Uknown wrote:I would like to point out that C++ does this with attributes instead[0]. If this was an attribute instead (like ` noreturn`), it would simplify interfacing with C++. It would also avoid the breaking change. [0]: eel.is/c++draft/DCL.attral.noreturnThe DIP mentions that, (e.g. I also don't like the syntax " noreturn int fun()"), but I don't understand what "other uses" of a type tBottom there are, which the DIP states are not possible in C++. Especially I want a section that explains how tBottom is different from void in such situations. For functions that don't return it's clear, but else?
Aug 09 2018
On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote:This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": [ ... ]Regarding the rationale: It should be pointed out that this is a further complication of the type-system (which is already more complex than what c++ has). That does impact generic code. My own experience with generic code has show that it is very hard (practically impossible) to write correct code, (correct meaning here working as intended, when instantiation succeeds) even when using template constraints. There is no explanation of when the additional optimizations would be actually relevant, Usually functions that don't return abort the program anyway. There not even an example piece of code where the newly enabled optimizations would make an impact. The point about other system languages having this feature is actually the most substantiated one :) I could accept a rationale which is about being able to simplify and extend the applicability of CFA (control flow analysis). Though even than CFA, not really that effective when is comes to making faster code. It is however quite good at subtly breaking code :( TLDR; I would kindly recommend further expansion on the interactions with the rest of the language and implications thereof.. Regards, Stefan
Aug 09 2018
On Thursday, 9 August 2018 at 10:47:37 UTC, Stefan Koch wrote:Regarding the rationale: It should be pointed out that this is a further complication of the type-system (which is already more complex than what c++ has). That does impact generic code. My own experience with generic code has show that it is very hard (practically impossible) to write correct code, (correct meaning here working as intended, when instantiation succeeds) even when using template constraints.Indeed.There is no explanation of when the additional optimizations would be actually relevant, Usually functions that don't return abort the program anyway.I presume Walter is talking about considering all branches that don't return to be cold and "outlining" them as much as possible so as to not pollute icache, which he already implemented. So I assume he's talking about propagating that information?There not even an example piece of code where the newly enabled optimizations would make an impact. The point about other system languages having this feature is actually the most substantiated one :)It was about that is was required to be competitive which I find to be a bizarre claim. But we already have this in LDC, GDC probably has something similar (whatever corresponds to __attribute__(noreturn)),and if you care about perf you are not using DMD.
Aug 09 2018
On Thursday, 9 August 2018 at 10:47:37 UTC, Stefan Koch wrote:There is no explanation of when the additional optimizations would be actually relevant, Usually functions that don't return abort the program anyway.Maybe total code size. OT: as for microoptimizations, what bugged me is a pattern when a method returns its first argument to enable chaining, if it returned void (or something like that) and the chained call reused the first argument of the preceding call how much that can save? But indeed introspection can be painful.
Aug 09 2018
On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote:This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": [...]How does this DIP interact with constructors and deconstructors as they are glorified void functions? -Alexander
Aug 09 2018
On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote:This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type":I hope there is a better name than Tbottom. A name like that is not consistent with the rest of the language. Why not Bottom?
Aug 09 2018
On Thursday, 9 August 2018 at 13:42:57 UTC, bachmeier wrote:On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote:according to the DIP, the name can be chosen arbitrarily as the type is retrieved via matching the type expression `typeof(assert(0))`This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type":I hope there is a better name than Tbottom. A name like that is not consistent with the rest of the language. Why not Bottom?
Aug 09 2018
On Thursday, 9 August 2018 at 13:45:54 UTC, Stefan Koch wrote:Okay. That's a lot worse. A type for a function that returns nothing and has an arbitrary name.I hope there is a better name than Tbottom. A name like that is not consistent with the rest of the language. Why not Bottom?according to the DIP, the name can be chosen arbitrarily as the type is retrieved via matching the type expression `typeof(assert(0))`
Aug 09 2018
On Thursday, 9 August 2018 at 13:42:57 UTC, bachmeier wrote:On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote:`bottom_t` or `never_t` are much better but perhaps this should actually be an attribute ` bottom`, or more a documenting: ` noreturn`?This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type":I hope there is a better name than Tbottom. A name like that is not consistent with the rest of the language. Why not Bottom?
Aug 09 2018
On Thursday, 9 August 2018 at 13:56:05 UTC, Gary Willoughby wrote:perhaps this should actually be an attribute ` bottom`, or more a documenting: ` noreturn`?Yes, it should.
Aug 09 2018
A better name for this type is `never`, which is the name of the TypeScript type with similar semantics. https://www.typescriptlang.org/docs/handbook/basic-types.html#never `nothing` is also a decent name, used in some other languages, but `never` makes it more obvious that a function never returns, and isn't as easy to confuse with `void`, which is a different kind of nothing.
Aug 09 2018
On Thursday, 9 August 2018 at 15:50:02 UTC, w0rp wrote:A better name for this type is `never`, which is the name of the TypeScript type with similar semantics. https://www.typescriptlang.org/docs/handbook/basic-types.html#never `nothing` is also a decent name, used in some other languages, but `never` makes it more obvious that a function never returns, and isn't as easy to confuse with `void`, which is a different kind of nothing.+1 for "never" - it's descriptive and readable. -Jon
Aug 10 2018
On Saturday, 11 August 2018 at 05:01:50 UTC, docandrew wrote:On Thursday, 9 August 2018 at 15:50:02 UTC, w0rp wrote:+1 for "never"A better name for this type is `never`, which is the name of the TypeScript type with similar semantics. https://www.typescriptlang.org/docs/handbook/basic-types.html#never `nothing` is also a decent name, used in some other languages, but `never` makes it more obvious that a function never returns, and isn't as easy to confuse with `void`, which is a different kind of nothing.+1 for "never" - it's descriptive and readable. -Jon
Aug 10 2018
On Saturday, 11 August 2018 at 05:01:50 UTC, docandrew wrote:On Thursday, 9 August 2018 at 15:50:02 UTC, w0rp wrote:And brings us closer to Rust, which is a good thing. But it does not matter, since the PR isn't suggesting any name for it -the user can create any alias of it he/she wants. Personally, I think the most accurate term would be "Paradox" but again it does not matter for sake of this DIP.A better name for this type is `never`, which is the name of the TypeScript type with similar semantics. https://www.typescriptlang.org/docs/handbook/basic-types.html#never `nothing` is also a decent name, used in some other languages, but `never` makes it more obvious that a function never returns, and isn't as easy to confuse with `void`, which is a different kind of nothing.+1 for "never" - it's descriptive and readable. -Jon
Aug 11 2018
On 09.08.2018 05:02, Mike Parker wrote:This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": https://github.com/dlang/DIPs/blob/8274b0f600075e4553b41c31f4b77be2d917 b40/DIPs/DIP1017.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 24, or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the Final Review and Formal Assessment by the language maintainers. Please familiarize yourself with the documentation for the Community Review before participating. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review Thanks in advance to all who participate.Copy-paste of my comment on the DIP pull request: "`Tbottom* → Tbottom` and `Tbottom[] → Tbottom` seem a bit unprincipled. I'd have rather expected to see `Tbottom* == typeof(null)` and `Tbottom[] == typeof([])`. In general, I'd advise against having special rules with regards to type construction, as special behavior like this can harm generic code." I think if we in fact want to have some sort of "bottom propagation" nonetheless, it should be expression-based, not type-based.
Aug 09 2018