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:
The benefit would be that null can be a regular pointer
constant (enum null = typeof((false)).init) instead of
a symbol with special meaning. I'd think it makes compiler
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((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
On Saturday, 11 August 2018 at 05:01:50 UTC, docandrew wrote:
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
On Saturday, 11 August 2018 at 05:01:50 UTC, docandrew wrote:
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
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
On Saturday, 11 August 2018 at 00:01:34 UTC, Timon Gehr wrote:
On 11.08.2018 01:40, Stefan Koch wrote:
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
On 11.08.2018 01:40, Stefan Koch wrote:
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.
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:
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
On Friday, 10 August 2018 at 12:42:37 UTC, Nicholas Wilson wrote:
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
On Friday, 10 August 2018 at 11:31:02 UTC, Dukc wrote:
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)))
How is that a good thing??? Also that is not specified in the
dip.
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)))
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
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:
`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:
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
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:
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:
The DIP makes the claim that:
*
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:
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
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/8274b0f600075e4553b41c31f4b77be2d917bb40/DIPs/DIP1017.md
All review-related feedback on and discussion of the DIP
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:
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
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
On Thursday, 9 August 2018 at 13:45:54 UTC, Stefan Koch wrote:
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
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.
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
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:
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
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:
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
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?
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
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
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
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]:
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
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
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
The first round of Community Review for DIP 1017, "Add Bottom
Type", has begun. To participate, please visit the review thread
for the details:
https://forum.dlang.org/post/bvyzkatgwlkiserqr...@forum.dlang.org
*Please leave all feedback in the review thread rather than here!*
Thanks!
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
34 matches
Mail list logo
