Re: proposed @noreturn attribute

I didn't look through all of the replies to this thread to check that this hasn't been mentioned yet, but TypeScript uses the 'never' return type for functions that never return. https://www.typescriptlang.org/docs/handbook/basic-types.html#never The type isn't used for any optimisations,

Re: proposed @noreturn attribute

On 07/19/2017 10:32 AM, Timon Gehr wrote: On 19.07.2017 14:13, Moritz Maxeiner wrote: On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote: a value of type bottom can be used to construct a value for any other type. AFAIK from type theory, bottom is defined as having no values (so

Re: proposed @noreturn attribute

On Wednesday, 19 July 2017 at 10:35:37 UTC, Stefan Koch wrote: On Wednesday, 19 July 2017 at 10:24:35 UTC, Marc Schütz wrote: On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu wrote: Perhaps we go the inverse route and define the bottom type as typeof(*null). Would that simplify

Re: proposed @noreturn attribute

On 20.07.2017 00:21, Tobias Müller wrote: Timon Gehr wrote: [...] What I am saying is: in a language with a bottom type, we can create a function: T f(T)(Bottom b){ return b; // assuming b converts to all types implicitly. } Within the function body, b is a value of

Re: proposed @noreturn attribute

Timon Gehr wrote: > [...] > What I am saying is: in a language with a bottom type, we can create a > function: > > T f(T)(Bottom b){ > return b; // assuming b converts to all types implicitly. > } > > Within the function body, b is a value of type Bottom. > We use a

Re: proposed @noreturn attribute

On 7/16/2017 6:03 AM, Timon Gehr wrote: pragma(noreturn) is indeed the simpler solution, as it does not interact with anything else. Pragmas are not supposed to change the semantics of the code, they are intended as directions to the compiler, such as: * optimization suggestions * embedding

Re: proposed @noreturn attribute

On 19.07.2017 17:14, Moritz Maxeiner wrote: On Wednesday, 19 July 2017 at 14:52:28 UTC, Timon Gehr wrote: On 19.07.2017 16:47, Moritz Maxeiner wrote: On Wednesday, 19 July 2017 at 14:32:24 UTC, Timon Gehr wrote: On 19.07.2017 14:13, Moritz Maxeiner wrote: On Wednesday, 19 July 2017 at

Re: proposed @noreturn attribute

On Wednesday, 19 July 2017 at 14:52:28 UTC, Timon Gehr wrote: On 19.07.2017 16:47, Moritz Maxeiner wrote: On Wednesday, 19 July 2017 at 14:32:24 UTC, Timon Gehr wrote: On 19.07.2017 14:13, Moritz Maxeiner wrote: On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote: a value of type

Re: proposed @noreturn attribute

On 19.07.2017 16:47, Moritz Maxeiner wrote: On Wednesday, 19 July 2017 at 14:32:24 UTC, Timon Gehr wrote: On 19.07.2017 14:13, Moritz Maxeiner wrote: On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote: a value of type bottom can be used to construct a value for any other type.

Re: proposed @noreturn attribute

On Wednesday, 19 July 2017 at 14:32:24 UTC, Timon Gehr wrote: On 19.07.2017 14:13, Moritz Maxeiner wrote: On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote: a value of type bottom can be used to construct a value for any other type. AFAIK from type theory, bottom is defined as

Re: proposed @noreturn attribute

On 19.07.2017 14:13, Moritz Maxeiner wrote: On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote: a value of type bottom can be used to construct a value for any other type. AFAIK from type theory, bottom is defined as having no values (so one can't reason about the relationship of

Re: proposed @noreturn attribute

Am Wed, 19 Jul 2017 12:13:40 + schrieb Moritz Maxeiner : > On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote: > > a value of type bottom can be used to construct a value for any > > other type. > > AFAIK from type theory, bottom is defined as having no

Re: proposed @noreturn attribute

On Wednesday, 19 July 2017 at 11:02:07 UTC, Marc Schütz wrote: On Wednesday, 12 July 2017 at 13:22:46 UTC, Meta wrote: D is not ML or Haskell or Idris. Rust has trod this ground before us and they saw it prudent to not make ! a first-class type. Only to turn around after they realized their

Re: proposed @noreturn attribute

On Wednesday, 19 July 2017 at 11:35:47 UTC, Timon Gehr wrote: a value of type bottom can be used to construct a value for any other type. AFAIK from type theory, bottom is defined as having no values (so one can't reason about the relationship of such non-existent value(s) to values of other

Re: proposed @noreturn attribute

On 19.07.2017 12:59, Stefan Koch wrote: On Wednesday, 19 July 2017 at 10:44:22 UTC, Timon Gehr wrote: No. Bottom is to types as typeof(null) is to class types. I fear you lost me again :) as far as I understood your previous explanation, every type is a subtype of bottom, is that incorrect

Re: proposed @noreturn attribute

On Wednesday, 12 July 2017 at 13:22:46 UTC, Meta wrote: D is not ML or Haskell or Idris. Rust has trod this ground before us and they saw it prudent to not make ! a first-class type. Only to turn around after they realized their mistake:

Re: proposed @noreturn attribute

On Wednesday, 19 July 2017 at 10:44:22 UTC, Timon Gehr wrote: No. Bottom is to types as typeof(null) is to class types. I fear you lost me again :) as far as I understood your previous explanation, every type is a subtype of bottom, is that incorrect ?

Re: proposed @noreturn attribute

On 19.07.2017 12:35, Stefan Koch wrote: On Wednesday, 19 July 2017 at 10:24:35 UTC, Marc Schütz wrote: On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu wrote: Perhaps we go the inverse route and define the bottom type as typeof(*null). Would that simplify matters? There is some

Re: proposed @noreturn attribute

On 19.07.2017 12:24, Marc Schütz wrote: On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu wrote: Perhaps we go the inverse route and define the bottom type as typeof(*null). Would that simplify matters? There is some good consistency about it: null: a pointer to anything. But

Re: proposed @noreturn attribute

On Wednesday, 19 July 2017 at 10:24:35 UTC, Marc Schütz wrote: On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu wrote: Perhaps we go the inverse route and define the bottom type as typeof(*null). Would that simplify matters? There is some good consistency about it: null: a

Re: proposed @noreturn attribute

On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu wrote: Perhaps we go the inverse route and define the bottom type as typeof(*null). Would that simplify matters? There is some good consistency about it: null: a pointer to anything. But can't be dereferenced. *null: well,

Re: proposed @noreturn attribute

On 7/18/2017 7:14 PM, Nicholas Wilson wrote: It describe the behaviour of the function: I think it is neither necessary nor a good idea to express it as a type. assert(0) is already accepted as a valid return statement of any type. I can't continue this without being repetitive, so we'll just

Re: proposed @noreturn attribute

On Wednesday, 19 July 2017 at 01:52:30 UTC, Walter Bright wrote: I know how noreturn attributes work - I implemented them decades ago in DMC and DMC++. They are supported by the DMD optimizer and back end. But they are a hack to the type system, and I suggest an unnecessary one. It

Re: proposed @noreturn attribute

On 7/18/2017 5:54 PM, Nicholas Wilson wrote: There is just something fundamentally wrong with: @noreturn int foo(); I would understand it to mean that if it were to return, foo would return an int but it is undefined behaviour for foo to dynamically return. That's the C++ behavior. I know

Re: proposed @noreturn attribute

On Tuesday, 18 July 2017 at 22:03:27 UTC, Walter Bright wrote: The issue here (for me) is to have a type system that matches type systems used in type theory. D already has strong abilities to do type calculus. Instead of inventing our own whackadoodle scheme, one hack at a time, why not match

Re: proposed @noreturn attribute

On Tuesday, 18 July 2017 at 22:03:27 UTC, Walter Bright wrote: On 7/17/2017 4:26 PM, H. S. Teoh via Digitalmars-d wrote: But the point is that so much time and effort is being spent on discussing and designing a feature that you have admitted yourself to be "rarely used". As a disinterested

Re: proposed @noreturn attribute

On 18.07.2017 23:35, Moritz Maxeiner wrote: Could you explain why `return foo();` is even legal for a `void foo() {}`? Because the ad-hoc decision to make void a type that is not really a type leads to unnecessary friction, and this exceptional rule removes the friction in one common

Re: proposed @noreturn attribute

On Tuesday, 18 July 2017 at 21:45:27 UTC, Adam D. Ruppe wrote: On Tuesday, 18 July 2017 at 21:35:21 UTC, Moritz Maxeiner wrote: Could you explain why `return foo();` is even legal for a `void foo() {}`? Suppose you are writing a template function that forwards: auto forward(alias fun,

Re: proposed @noreturn attribute

On 7/17/2017 4:26 PM, H. S. Teoh via Digitalmars-d wrote: But the point is that so much time and effort is being spent on discussing and designing a feature that you have admitted yourself to be "rarely used". As a disinterested bystander I find it somewhat amusing (and sad) to see so much

Re: proposed @noreturn attribute

On Tuesday, 18 July 2017 at 21:35:21 UTC, Moritz Maxeiner wrote: Could you explain why `return foo();` is even legal for a `void foo() {}`? Suppose you are writing a template function that forwards: auto forward(alias fun, T...)(T args) { return fun(args); } It just saves you from having

Re: proposed @noreturn attribute

On Tuesday, 18 July 2017 at 20:49:56 UTC, Timon Gehr wrote: On 18.07.2017 20:46, Yuxuan Shui wrote: On Tuesday, 18 July 2017 at 15:26:59 UTC, Timon Gehr wrote: On 18.07.2017 14:19, Stefan Koch wrote: [...] D has a C-inspired first-order type system, so it is not necessarily crucial to have

Re: proposed @noreturn attribute

On 18.07.2017 20:46, Yuxuan Shui wrote: On Tuesday, 18 July 2017 at 15:26:59 UTC, Timon Gehr wrote: On 18.07.2017 14:19, Stefan Koch wrote: [...] D has a C-inspired first-order type system, so it is not necessarily crucial to have it in D. (The reason I got involved in this thread is that

Re: proposed @noreturn attribute

On Tuesday, 18 July 2017 at 15:26:59 UTC, Timon Gehr wrote: On 18.07.2017 14:19, Stefan Koch wrote: [...] D has a C-inspired first-order type system, so it is not necessarily crucial to have it in D. (The reason I got involved in this thread is that it was proposed to add Bottom as a type

Re: proposed @noreturn attribute

On Monday, 17 July 2017 at 18:54:37 UTC, H. S. Teoh wrote: On Mon, Jul 17, 2017 at 02:10:27PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] [...] IMO, the observations "used rarely" and "attention-seeking notation" are better satisfied by an attribute named @noreturn than some

Re: proposed @noreturn attribute

On 18.07.2017 14:19, Stefan Koch wrote: On Tuesday, 18 July 2017 at 12:15:06 UTC, Timon Gehr wrote: On 18.07.2017 12:17, John Colvin wrote: Better to just not define it. That's not an option. Bottom is a subtype of all types. It cannot remove members, even static ones. Timon, how

Re: proposed @noreturn attribute

On Tuesday, 18 July 2017 at 12:15:06 UTC, Timon Gehr wrote: On 18.07.2017 12:17, John Colvin wrote: Better to just not define it. That's not an option. Bottom is a subtype of all types. It cannot remove members, even static ones. Timon, how important is it to actually have bottom ? ...

Re: proposed @noreturn attribute

On 18.07.2017 12:17, John Colvin wrote: Better to just not define it. That's not an option. Bottom is a subtype of all types. It cannot remove members, even static ones.

Re: proposed @noreturn attribute

On Tuesday, 18 July 2017 at 10:17:17 UTC, John Colvin wrote: how do I store the type "int" in memory? new Type(TYENUM.Tint32); :o)

Re: proposed @noreturn attribute

On Monday, 17 July 2017 at 23:01:40 UTC, Walter Bright wrote: On 7/16/2017 5:41 AM, Timon Gehr wrote: struct S{ T x; Bottom everything; } turns the entire struct into an empty type. It is therefore most natural to say that Bottom.sizeof == ∞. (It's the only choice for which S.sizeof

Re: proposed @noreturn attribute

On Monday, 17 July 2017 at 18:10:27 UTC, Andrei Alexandrescu wrote: On 7/17/17 11:39 AM, Olivier FAURE wrote: I'd really prefer if you avoided the whole `typeof(assert(0))` thing. First off, it's way too verbose for a simple concept. Noted, thanks. I won't debate this much but for now I

Re: proposed @noreturn attribute

On 18.07.2017 03:06, Walter Bright wrote: On 7/17/2017 5:13 PM, Timon Gehr wrote: (Reminds me of divide by 0 discussions in calculus class.) The reason division by 0 is left undefined is that instead saying 1/0 = ∞ introduces a new number ∞ that does not play nice with the axioms of a

Re: proposed @noreturn attribute

On 7/17/2017 5:13 PM, Timon Gehr wrote: (Reminds me of divide by 0 discussions in calculus class.) The reason division by 0 is left undefined is that instead saying 1/0 = ∞ introduces a new number ∞ that does not play nice with the axioms of a complete ordered field. The question for

Re: proposed @noreturn attribute

On Monday, 17 July 2017 at 18:54:37 UTC, H. S. Teoh wrote: IMO, the observations "used rarely" and "attention-seeking notation" are better satisfied by an attribute named @noreturn than some strange, convoluted, arcane invocation like `typeof(assert(0))`. Because: (1) "used rarely" means it

Re: proposed @noreturn attribute

On 7/17/2017 5:06 PM, Seb via Digitalmars-d wrote: I can't agree more. This is textbook procrastination and bike-shedding [1]! There are dozens of open regressions that could have fixed or great, stalled PRs that could have been reviewed. In fact if only PRs would be as heartily reviewed as

Re: proposed @noreturn attribute

On 18.07.2017 01:01, Walter Bright wrote: ... But if Bottom does not exist, then S doesn't exist either, and hence the < size relationship has no meaning. ... Both Bottom and S exist, but they have no instances. (Reminds me of divide by 0 discussions in calculus class.) The reason

Re: proposed @noreturn attribute

On Monday, 17 July 2017 at 23:26:18 UTC, H. S. Teoh wrote: Actually, I don't really care enough about this issue to want it to be implemented one way or another, as long as there is *some* way to annotate a non-returning function. But the point is that so much time and effort is being spent

Re: proposed @noreturn attribute

On Mon, Jul 17, 2017 at 06:42:02PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 7/17/17 2:54 PM, H. S. Teoh via Digitalmars-d wrote: > > I see `typeof(assert(0))` as the same kind of over-engineering of > > something trivially solved and relatively unimportant ("rarely > > used") that

Re: proposed @noreturn attribute

On 7/16/2017 5:41 AM, Timon Gehr wrote: struct S{ T x; Bottom everything; } turns the entire struct into an empty type. It is therefore most natural to say that Bottom.sizeof == ∞. (It's the only choice for which S.sizeof == Bottom.sizeof.) Another way to think about it: If

Re: proposed @noreturn attribute

On 7/16/2017 1:15 PM, Timon Gehr wrote: In this case, Bottom.sizeof is a value of type Bottom, which must not exist. T.sizeof is a value of type size_t, not type T.

Re: proposed @noreturn attribute

On 7/17/17 2:54 PM, H. S. Teoh via Digitalmars-d wrote: I see `typeof(assert(0))` as the same kind of over-engineering of something trivially solved and relatively unimportant ("rarely used") that has unfortunately plagued C++ design and led C++ to become the mess it is today. It's sad to see D

Re: proposed @noreturn attribute

On Monday, 17 July 2017 at 18:54:37 UTC, H. S. Teoh wrote: On Mon, Jul 17, 2017 at 02:10:27PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: On 7/17/17 11:39 AM, Olivier FAURE wrote: > I'd really prefer if you avoided the whole > `typeof(assert(0))` > thing. > > First off, it's way too

Re: proposed @noreturn attribute

On Mon, Jul 17, 2017 at 02:10:27PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 7/17/17 11:39 AM, Olivier FAURE wrote: > > I'd really prefer if you avoided the whole `typeof(assert(0))` > > thing. > > > > First off, it's way too verbose for a simple concept. > > Noted, thanks. I

Re: proposed @noreturn attribute

On 7/17/17 11:39 AM, Olivier FAURE wrote: I'd really prefer if you avoided the whole `typeof(assert(0))` thing. First off, it's way too verbose for a simple concept. Noted, thanks. I won't debate this much but for now I disagree. The "no return" type has several particular properties that

Re: proposed @noreturn attribute

On Monday, 17 July 2017 at 15:39:30 UTC, Olivier FAURE wrote: On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu wrote: An issue is that we already have typeof(null). typeof(null) and typeof(assert(0))* are two ways to specify almost the same thing. One question is whether

Re: proposed @noreturn attribute

On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu wrote: An issue is that we already have typeof(null). typeof(null) and typeof(assert(0))* are two ways to specify almost the same thing. One question is whether typeof(assert(0))* and typeof(null) should be the same, or if the former

Re: proposed @noreturn attribute

On Sunday, 16 July 2017 at 20:15:11 UTC, Timon Gehr wrote: On 16.07.2017 21:49, Guillaume Boucher wrote: On Sunday, 16 July 2017 at 12:41:06 UTC, Timon Gehr wrote: It is therefore most natural to say that Bottom.sizeof == ∞. True, but size_t.max doesn't have the properties of ∞. The only

Re: proposed @noreturn attribute

On Sunday, 16 July 2017 at 20:04:25 UTC, Timon Gehr wrote: The issue isn't purism, it is type safety. If you create an EvolvedPenguin, upcast it to a Penguin and call the fly method you get UB. So noreturn would indeed need to enforce that all overrides are also noreturn. I see it as some

Re: proposed @noreturn attribute

On 07/13/2017 01:25 PM, Timon Gehr wrote: On Wednesday, 12 July 2017 at 14:23:15 UTC, Andrei Alexandrescu wrote: On 07/12/2017 05:32 AM, Timon Gehr wrote: On 09.07.2017 23:45, Meta wrote: ... Another case that we should probably just statically disallow: ... > This obviously doesn't make any

Re: proposed @noreturn attribute

On 07/16/2017 04:15 PM, Timon Gehr wrote: On 16.07.2017 21:49, Guillaume Boucher wrote: On Sunday, 16 July 2017 at 12:41:06 UTC, Timon Gehr wrote: It is therefore most natural to say that Bottom.sizeof == ∞. True, but size_t.max doesn't have the properties of ∞. The only sane choice to me

Re: proposed @noreturn attribute

On 16.07.2017 21:49, Guillaume Boucher wrote: On Sunday, 16 July 2017 at 12:41:06 UTC, Timon Gehr wrote: It is therefore most natural to say that Bottom.sizeof == ∞. True, but size_t.max doesn't have the properties of ∞. The only sane choice to me seems to be a value of type Bottom, i.e.

Re: proposed @noreturn attribute

On 16.07.2017 21:49, Guillaume Boucher wrote: I'd say a function with return type Bottom can override any function in the base class. That solves the "Penguin : Bird" step, but not "EvolvedPenguin : Penguin" (which can fly). Andrei argues that my example don't comply with a puristic

Re: proposed @noreturn attribute

On Sunday, 16 July 2017 at 12:41:06 UTC, Timon Gehr wrote: It is therefore most natural to say that Bottom.sizeof == ∞. True, but size_t.max doesn't have the properties of ∞. The only sane choice to me seems to be a value of type Bottom, i.e. is(typeof(Bottom.sizeof) == Bottom).

Re: proposed @noreturn attribute

On Sunday, 16 July 2017 at 13:03:40 UTC, Timon Gehr wrote: I don't think that's true. A Bottom type does not cover all use cases of @noreturn/@pragma(noreturn). ... I think it does, but it is a significantly more invasive language change. The best you can hope for is that any code with

Re: proposed @noreturn attribute

On 14.07.2017 17:39, Guillaume Boucher wrote: On Monday, 10 July 2017 at 04:02:59 UTC, Nicholas Wilson wrote: 1)@noreturn 2)@disable(return) 3)none w.r.t optimisation assuming both 1 & 3 impact DMD equally [...] I don't think that's true. A Bottom type does not cover all use cases of

Re: proposed @noreturn attribute

On 07/15/2017 11:30 PM, Walter Bright wrote: On 7/13/2017 5:18 PM, Andrei Alexandrescu wrote: On 7/13/17 2:37 PM, Timon Gehr wrote: On Thursday, 13 July 2017 at 17:25:18 UTC, Timon Gehr wrote: Anyway, my assertion that Bottom cannot be a subtype of all other types was actually incorrect: the

Re: proposed @noreturn attribute

On 16.07.2017 05:30, Walter Bright wrote: On 7/13/2017 5:18 PM, Andrei Alexandrescu wrote: On 7/13/17 2:37 PM, Timon Gehr wrote: On Thursday, 13 July 2017 at 17:25:18 UTC, Timon Gehr wrote: Anyway, my assertion that Bottom cannot be a subtype of all other types was actually incorrect: the

Re: proposed @noreturn attribute

On 7/13/2017 5:18 PM, Andrei Alexandrescu wrote: On 7/13/17 2:37 PM, Timon Gehr wrote: On Thursday, 13 July 2017 at 17:25:18 UTC, Timon Gehr wrote: Anyway, my assertion that Bottom cannot be a subtype of all other types was actually incorrect: the compiler does not need to generate code for

Re: proposed @noreturn attribute

On 07/14/2017 03:06 PM, Lurker wrote: On Friday, 14 July 2017 at 15:39:01 UTC, Guillaume Boucher wrote: Example 1: Polymorphism class Bird { void fly() { ... } }; class Penguin : Bird { override void fly() @pragma(noreturn) { assert(0); } }; class EvolvedPenguin : Penguin { override void

Re: proposed @noreturn attribute

On Friday, 14 July 2017 at 15:39:01 UTC, Guillaume Boucher wrote: Example 1: Polymorphism class Bird { void fly() { ... } }; class Penguin : Bird { override void fly() @pragma(noreturn) { assert(0); } }; class EvolvedPenguin : Penguin { override void fly() { ... } }; No matter how you

Re: proposed @noreturn attribute

On Monday, 10 July 2017 at 04:02:59 UTC, Nicholas Wilson wrote: 1)@noreturn 2)@disable(return) 3)none w.r.t optimisation assuming both 1 & 3 impact DMD equally [...] I don't think that's true. A Bottom type does not cover all use cases of @noreturn/@pragma(noreturn). Example 1:

Re: proposed @noreturn attribute

On 7/13/17 2:37 PM, Timon Gehr wrote: On Thursday, 13 July 2017 at 17:25:18 UTC, Timon Gehr wrote: Anyway, my assertion that Bottom cannot be a subtype of all other types was actually incorrect: the compiler does not need to generate code for implicit conversion from Bottom to some other type,

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 20:27:11 UTC, H. S. Teoh wrote: Also, a @noreturn attribute would allow overriding a non-void class method with a @noreturn one (e.g. the derived class is a sentinel object that forces an exception / termination upon calling that method), whereas you can't do that

Re: proposed @noreturn attribute

On Thursday, 13 July 2017 at 17:25:18 UTC, Timon Gehr wrote: Anyway, my assertion that Bottom cannot be a subtype of all other types was actually incorrect: the compiler does not need to generate code for implicit conversion from Bottom to some other type, so it can be treated as a subtype.

Re: proposed @noreturn attribute

On Wednesday, 12 July 2017 at 14:23:15 UTC, Andrei Alexandrescu wrote: On 07/12/2017 05:32 AM, Timon Gehr wrote: On 09.07.2017 23:45, Meta wrote: ... Another case that we should probably just statically disallow: ... > This obviously doesn't make any sense anyway ... > I don't see a reason for

Re: proposed @noreturn attribute

On 07/12/2017 05:32 AM, Timon Gehr wrote: On 09.07.2017 23:45, Meta wrote: ... Another case that we should probably just statically disallow: ... > This obviously doesn't make any sense anyway ... > I don't see a reason for us to ever need to do that Sorry, but this thinking has no place in

Re: proposed @noreturn attribute

On Wednesday, 12 July 2017 at 09:32:32 UTC, Timon Gehr wrote: On 09.07.2017 23:45, Meta wrote: ... Another case that we should probably just statically disallow: ... > This obviously doesn't make any sense anyway ... > I don't see a reason for us to ever need to do that Sorry, but this thinking

Re: proposed @noreturn attribute

On 09.07.2017 23:45, Meta wrote: ... Another case that we should probably just statically disallow: ... > This obviously doesn't make any sense anyway ... > I don't see a reason for us to ever need to do that Sorry, but this thinking has no place in type system design. This is precisely how you

Re: proposed @noreturn attribute

On 11.07.2017 19:27, Meta wrote: On Tuesday, 11 July 2017 at 08:29:12 UTC, Timon Gehr wrote: On 10.07.2017 18:23, Meta wrote: ... problems with stuff like typeof(null)* etc. because for the most part it's just a regular type, unlike Bottom. Bottom is just a regular type. It's a regular

Re: proposed @noreturn attribute

On 12.07.2017 03:50, Andrei Alexandrescu wrote: On 7/11/17 4:29 AM, Timon Gehr wrote: On 10.07.2017 18:23, Meta wrote: ... problems with stuff like typeof(null)* etc. because for the most part it's just a regular type, unlike Bottom. Bottom is just a regular type. Wouldn't the fact that

Re: proposed @noreturn attribute

On 7/11/17 4:29 AM, Timon Gehr wrote: On 10.07.2017 18:23, Meta wrote: ... problems with stuff like typeof(null)* etc. because for the most part it's just a regular type, unlike Bottom. Bottom is just a regular type. Wouldn't the fact that it's a subtype of all other types make it a bit

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 12:18:38 UTC, Andrei Alexandrescu wrote: On 7/8/17 7:07 AM, bachmeier wrote: On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote: Having an @noreturn attribute will take care of that: @noreturn void ThisFunctionExits(); Why should this be an

Re: proposed @noreturn attribute

On Monday, 10 July 2017 at 20:00:10 UTC, Steven Schveighoffer wrote: This means that you get errors for some instantiations. Which ironically means you'd need to do something like this: void foo(alias f)() { f(); static if(!isNoreturn!f) { auto a = 5; ...// etc. } }

Re: proposed @noreturn attribute

On Tuesday, 11 July 2017 at 08:29:12 UTC, Timon Gehr wrote: On 10.07.2017 18:23, Meta wrote: ... problems with stuff like typeof(null)* etc. because for the most part it's just a regular type, unlike Bottom. Bottom is just a regular type. It's a regular type with unusual behaviour due to

Re: proposed @noreturn attribute

On 10.07.2017 04:44, Walter Bright wrote: Let's call the bottom type 'B' for the moment, for convenience. If we think of it like a floating point NaN, It's not. It's an empty type. then any type construction of B yields a B: const(B) -> B I don't see why to add this special case.

Re: proposed @noreturn attribute

On 10.07.2017 18:23, Meta wrote: ... problems with stuff like typeof(null)* etc. because for the most part it's just a regular type, unlike Bottom. Bottom is just a regular type.

Re: proposed @noreturn attribute

On 2017-07-11 09:37, Iain Buclaw via Digitalmars-d wrote: Right, you can't put noreturn on enforce itself, but you can on the internal bailOut function called by enforce. Ah, but I though it would just contain a "throw" for the case the the condition is false. I see now that it doesn't. --

Re: proposed @noreturn attribute

On 08.07.2017 12:15, Walter Bright wrote: C compilers (and by extension C++ compilers) usually have an extension which allows a function to be marked as one that never returns. The point of this is it enables improved data flow analysis and better code being generated. Noreturn functions

Re: proposed @noreturn attribute

On 11 July 2017 at 08:46, Jacob Carlborg via Digitalmars-d wrote: > On 2017-07-10 22:00, Walter Bright wrote: > >> Yes. Not having it makes enforce(), for example, generate poor code. > > > Not sure I understand. "enforce" will return if the condition is true. >

Re: proposed @noreturn attribute

On 2017-07-10 22:00, Walter Bright wrote: Yes. Not having it makes enforce(), for example, generate poor code. Not sure I understand. "enforce" will return if the condition is true. -- /Jacob Carlborg

Re: proposed @noreturn attribute

Am Sat, 8 Jul 2017 03:15:39 -0700 schrieb Walter Bright : > […] > > Having an @noreturn attribute will take care of that: > > @noreturn void ThisFunctionExits(); > > Yes, it's another builtin attribute and attributes are arguably a failure in > language design.

Re: proposed @noreturn attribute

On 7/10/2017 12:02 PM, Jacob Carlborg wrote: Are those few cases worth optimizing for? Yes. Not having it makes enforce(), for example, generate poor code.

Re: proposed @noreturn attribute

On 7/10/17 3:05 PM, Meta wrote: On Monday, 10 July 2017 at 18:50:54 UTC, Steven Schveighoffer wrote: On 7/10/17 2:38 PM, Walter Bright wrote: On 7/10/2017 4:00 AM, Steven Schveighoffer wrote: But I have to ask, what is the benefit of statically determining that a function is noreturn? It is

Re: proposed @noreturn attribute

On 7/10/2017 12:05 PM, Meta wrote: Currently not. This is either a bug or the compiler's flow analysis is not robust enough to detect this case. Flow analysis relies on the function's signature, not its implementation, and currently the signature contains no information about noreturn.

Re: proposed @noreturn attribute

Jacob Carlborg wrote: I'm going to ask the stupid question: I understand that this is for the compiler to generate better code. But, since the attribute (or whatever it is) indicates that a function won't return, it can only be used in very few cases. Are those few cases worth optimizing for?

Re: proposed @noreturn attribute

On Monday, 10 July 2017 at 18:09:54 UTC, H. S. Teoh wrote: On Sun, Jul 09, 2017 at 02:49:35PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: On 07/09/2017 06:51 AM, Daniel N wrote: > On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote: > > On Saturday, 8 July 2017 at 10:15:39 UTC,

Re: proposed @noreturn attribute

On Monday, 10 July 2017 at 18:50:54 UTC, Steven Schveighoffer wrote: On 7/10/17 2:38 PM, Walter Bright wrote: On 7/10/2017 4:00 AM, Steven Schveighoffer wrote: But I have to ask, what is the benefit of statically determining that a function is noreturn? It is useful anywhere dataflow

Re: proposed @noreturn attribute

On 2017-07-08 12:15, Walter Bright wrote: C compilers (and by extension C++ compilers) usually have an extension which allows a function to be marked as one that never returns. The point of this is it enables improved data flow analysis and better code being generated. Noreturn functions crop

Re: proposed @noreturn attribute

On 7/10/17 2:38 PM, Walter Bright wrote: On 7/10/2017 4:00 AM, Steven Schveighoffer wrote: But I have to ask, what is the benefit of statically determining that a function is noreturn? It is useful anywhere dataflow analysis is useful. FunctionThatDoesnotReturn(); a = b; // error:

Re: proposed @noreturn attribute

On 7/10/2017 4:00 AM, Steven Schveighoffer wrote: But I have to ask, what is the benefit of statically determining that a function is noreturn? It is useful anywhere dataflow analysis is useful. FunctionThatDoesnotReturn(); a = b; // error: unreachable code

Re: proposed @noreturn attribute

On Sun, Jul 09, 2017 at 02:49:35PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > On 07/09/2017 06:51 AM, Daniel N wrote: > > On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote: > > > On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote: > > > > > > > Has anyone a better

  1   2   >