nt val);
#include
_Noreturn void abort(void);
#include
_Noreturn void exit(int status);
#include
_Noreturn void _Exit(int status);
#include
_Noreturn void quick_exit(int status);
GNU C has a noreturn attribute since a lot of time. I don't fully understand
why such attribute is so
Hi,
If memory serves me right, there were some proposals in the past to add
a @noreturn attribute to the language. Where did this go?
In writing unwinding mechanisms for my VM, I find myself actually
needing some sort of @noreturn function attribute that would tell the
compiler that the
ld be nice however if you can give hints to
the compiler to let it know that a function is never going to return.
Example:
@noreturn void fatal()
{
print("Error");
exit(1);
}
The 'noreturn' keyword would tell the compiler that 'fatal' cannot return, and
can
On Saturday, 24 December 2011 at 20:09:46 UTC, bearophile wrote:
GNU C has a noreturn attribute since a lot of time. I don't
fully understand why such attribute is so useful in C programs,
but is something like a @noreturn function attribute useful in
D too? Maybe to implement a better
On Sat, Dec 24, 2011 at 2:09 PM, bearophile wrote:
>
> I don't fully understand why such attribute is so useful in C programs
>
> Bye,
> bearophile
>
Functions are like people. Sometimes they go places that's so beautiful
that they never want to return.
On 12/24/2011 06:58 PM, Vladimir Panteleev wrote:
On Saturday, 24 December 2011 at 20:09:46 UTC, bearophile wrote:
GNU C has a noreturn attribute since a lot of time. I don't fully
understand why such attribute is so useful in C programs, but is
something like a @noreturn function attr
On Saturday, December 24, 2011 22:26:02 Andrei Alexandrescu wrote:
> On 12/24/2011 06:58 PM, Vladimir Panteleev wrote:
> > On Saturday, 24 December 2011 at 20:09:46 UTC, bearophile wrote:
> >> GNU C has a noreturn attribute since a lot of time. I don't fully
> >>
On 13 May 2012 17:13, Alex Rønne Petersen wrote:
> Hi,
>
> If memory serves me right, there were some proposals in the past to add a
> @noreturn attribute to the language. Where did this go?
>
> In writing unwinding mechanisms for my VM, I find myself actually needing
> s
Alex Rønne Petersen:
In writing unwinding mechanisms for my VM, I find myself
actually needing some sort of @noreturn function attribute that
would tell the compiler that the function does not return,
Maybe Walter will listen you more if you show an example of
where/why you would use
On 14-05-2012 14:13, Alex Rønne Petersen wrote:
On 14-05-2012 13:53, bearophile wrote:
Alex Rønne Petersen:
In writing unwinding mechanisms for my VM, I find myself actually
needing some sort of @noreturn function attribute that would tell the
compiler that the function does not return
On 14-05-2012 13:53, bearophile wrote:
Alex Rønne Petersen:
In writing unwinding mechanisms for my VM, I find myself actually
needing some sort of @noreturn function attribute that would tell the
compiler that the function does not return,
Maybe Walter will listen you more if you show an
On 14 May 2012 13:21, Alex Rønne Petersen wrote:
> On 14-05-2012 14:13, Alex Rønne Petersen wrote:
>>
>> On 14-05-2012 13:53, bearophile wrote:
>>>
>>> Alex Rønne Petersen:
>>>
>>>> In writing unwinding mechanisms for my VM, I find myself
On 05/13/2012 06:13 PM, Alex Rønne Petersen wrote:
Hi,
If memory serves me right, there were some proposals in the past to add
a @noreturn attribute to the language. Where did this go?
In writing unwinding mechanisms for my VM, I find myself actually
needing some sort of @noreturn function
On 14-05-2012 23:59, Timon Gehr wrote:
On 05/13/2012 06:13 PM, Alex Rønne Petersen wrote:
Hi,
If memory serves me right, there were some proposals in the past to add
a @noreturn attribute to the language. Where did this go?
In writing unwinding mechanisms for my VM, I find myself actually
On 05/15/2012 12:14 AM, Alex Rønne Petersen wrote:
On 14-05-2012 23:59, Timon Gehr wrote:
On 05/13/2012 06:13 PM, Alex Rønne Petersen wrote:
Hi,
If memory serves me right, there were some proposals in the past to add
a @noreturn attribute to the language. Where did this go?
In writing
On Monday, May 14, 2012 23:59:19 Timon Gehr wrote:
> On 05/13/2012 06:13 PM, Alex Rønne Petersen wrote:
> > Hi,
> >
> > If memory serves me right, there were some proposals in the past to add
> > a @noreturn attribute to the language. Where did this go?
> >
&g
On 05/14/12 23:59, Timon Gehr wrote:
> On 05/13/2012 06:13 PM, Alex Rønne Petersen wrote:
>> Hi,
>>
>> If memory serves me right, there were some proposals in the past to add
>> a @noreturn attribute to the language. Where did this go?
>>
>> In writing unwind
;>> If memory serves me right, there were some proposals in the past to add
>>>> a @noreturn attribute to the language. Where did this go?
>>>>
>>>> In writing unwinding mechanisms for my VM, I find myself actually
>>>> needing some sort of @nore
On 14 May 2012 22:59, Timon Gehr wrote:
> On 05/13/2012 06:13 PM, Alex Rønne Petersen wrote:
>>
>> Hi,
>>
>> If memory serves me right, there were some proposals in the past to add
>> a @noreturn attribute to the language. Where did this go?
>>
>> In w
On Mon, 14 May 2012 17:59:19 -0400, Timon Gehr wrote:
On 05/13/2012 06:13 PM, Alex Rønne Petersen wrote:
Hi,
If memory serves me right, there were some proposals in the past to add
a @noreturn attribute to the language. Where did this go?
In writing unwinding mechanisms for my VM, I find
On 05/16/2012 02:27 PM, Steven Schveighoffer wrote:
On Mon, 14 May 2012 17:59:19 -0400, Timon Gehr wrote:
On 05/13/2012 06:13 PM, Alex Rønne Petersen wrote:
Hi,
If memory serves me right, there were some proposals in the past to add
a @noreturn attribute to the language. Where did this go
bug,
they are not for DMD.
OK, then I would support this as a method of specifying @noreturn
BTW, is this bug reported?
-Steve
supposed to be part of the method signature. Due to a
bug, they are not for DMD.
OK, then I would support this as a method of specifying @noreturn
BTW, is this bug reported?
-Steve
Yes. http://d.puremagic.com/issues/show_bug.cgi?id=6549
Stewart has turned it into an enhancement, but it is
>
> Thoughts?
I really, really like the idea.
Iain Buclaw:
> @noreturn void fatal()
> {
> print("Error");
> exit(1);
> }
See also the same feature in GNU C:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bnoreturn_007d-function-attribute-2455
Bye,
bearophile
'assert(0)'
> statement at the end of a function body. It would be nice however if you
> can give hints to the compiler to let it know that a function is never
> going to return.
>
> Example:
>
> @noreturn void fatal()
> {
> print("Error");
>
ntly in D2, you must either have a 'return' or 'assert(0)'
statement at the end of a function body. It would be nice however if you
can give hints to the compiler to let it know that a function is never
going to return.
Example:
@noreturn void fatal()
{
print("Error&qu
compiler know about
> > this. Currently in D2, you must either have a 'return' or 'assert(0)'
> > statement at the end of a function body. It would be nice however if you
> > can give hints to the compiler to let it know that a function is never
> > going t
gt;>> you can give hints to the compiler to let it know that a function is
>>> never going to return.
>>>
>>> Example:
>>>
>>> @noreturn void fatal()
>>> {
>>> print("Error");
>>> exit(1);
>>> }
>>
tement at
the end of a function body. It would be nice however if you can give hints to
the compiler to let it know that a function is never going to return.
Example:
@noreturn void fatal()
{
print("Error");
exit(1);
}
The 'noreturn' keyword would tell the compil
Iain Buclaw Wrote:
>
>
> Thoughts?
This can be a great idea.
In the same way, I saw something that can be good too about returned values in
Nimrod :
http://force7.de/nimrod/tut1.html#discard-statement
Hope the explanation is sufficient. This way, the programmer knows when he
"throws away"
r 'assert(0)' statement at
> the end of a function body. It would be nice however if you can give hints to
> the compiler to let it know that a function is never going to return.
>
> Example:
>
> @noreturn void fatal()
> {
> print("Error");
>
#x27;return' or 'assert(0)' statement at
the end of a function body. It would be nice however if you can give hints to
the compiler to let it know that a function is never going to return.
Example:
@noreturn void fatal()
{
print("Error");
exit(1);
}
The 'noretu
ler know about this.
> > Currently in D2, you must either have a 'return' or 'assert(0)' statement at
> > the end of a function body. It would be nice however if you can give hints
> > to
> > the compiler to let it know that a function is never going t
hints
> >> to
> >> the compiler to let it know that a function is never going to return.
> >>
> >> Example:
> >>
> >> @noreturn void fatal()
> >> {
> >> print("Error");
> >> exit(1);
> >> }
> >>
Ezneh:
> I saw something that can be good too about returned values in Nimrod :
> http://force7.de/nimrod/tut1.html#discard-statement
> Hope the explanation is sufficient. This way, the programmer knows when he
> "throws away" a returned value.
> I think that could be great too.
In C-like langu
On 10/21/2010 05:54, Iain Buclaw wrote:
> @noreturn void fatal()
> {
> print("Error");
> exit(1);
> }
> Thoughts?
This looks wrong to me. 'fatal' returns type 'void', except that it
doesn't. I would prefer this:
null_type fatal()
== Quote from Rainer Deyke (rain...@eldwood.com)'s article
> On 10/21/2010 05:54, Iain Buclaw wrote:
> > @noreturn void fatal()
> > {
> > print("Error");
> > exit(1);
> > }
> > Thoughts?
> This looks wrong to me. 'fatal'
On 10/21/10 12:21 CDT, Rainer Deyke wrote:
Feel free to think of a better name than 'null_type'.
It's a theory classic called "none" or "bottom". It's the bottom of the
subtyping lattice, the subtype of all possible types, a type that can
never be instantiated.
The feature is nice to have b
Daniel Gibson, el 21 de octubre a las 17:15 me escribiste:
> >You want to include in the language what you can do (or at least could)
> >do in GDC using:
> >
> >pragma(GNU_attribute, noreturn)) void fatal()
> >{
> > print("Error");
> >
r have a 'return' or 'assert(0)' statement
> at
> the end of a function body. It would be nice however if you can give hints
> to
> the compiler to let it know that a function is never going to return.
>
> Example:
>
> @noreturn void fatal()
> {
>
Nick Sabalausky:
> One of the nice things about that is you don't have to provide a "fake"
> return type. For instance, with your "@noreturn": "@noreturn int foo()"
> would be legal, but wouldn't make any sence. And in a way, even "@nor
bearophile, el 21 de octubre a las 17:35 me escribiste:
> Nick Sabalausky:
>
> > One of the nice things about that is you don't have to provide a "fake"
> > return type. For instance, with your "@noreturn": "@noreturn int foo()"
> >
== Quote from Leandro Lucarella (l...@llucax.com.ar)'s article
> bearophile, el 21 de octubre a las 17:35 me escribiste:
> > Nick Sabalausky:
> >
> > > One of the nice things about that is you don't have to provide a "fake"
> > > return type. Fo
nt' function that is
> marked as
> noreturn?
A 'void' function returns, therefore it conceptually returns a value.
For generic programming, it is useful to treat 'void' as a type like any
other, except that it only has one possible value (and therefore enc
On 21/10/2010 12:54, Iain Buclaw wrote:
@noreturn
What are you taking to be the semantics of '@'?
void fatal()
{
print("Error");
exit(1);
}
The 'noreturn' keyword would tell the compiler that 'fatal' cannot return, and
can then optimis
value (or
> > result).
> > Are you perhaps confusing it with to, lets say an 'int' function that is
> > marked as
> > noreturn?
> A 'void' function returns, therefore it conceptually returns a value.
> For generic programming, it is useful to tr
On 22/10/2010 03:44, Rainer Deyke wrote:
A 'void' function returns, therefore it conceptually returns a value.
For generic programming, it is useful to treat 'void' as a type like any
other, except that it only has one possible value (and therefore encodes
no information and requires no storage)
Ada 95 too has a No_return pragma, see page 12-14 of the PDF file here, it
explains various things:
http://www.adacore.com/2006/02/02/ada-2005-rationale-exceptions-generics-etc-part-6-of-8/
Bye,
bearophile
On 10/22/10 19:24 CDT, bearophile wrote:
Ada 95 too has a No_return pragma, see page 12-14 of the PDF file here, it
explains various things:
http://www.adacore.com/2006/02/02/ada-2005-rationale-exceptions-generics-etc-part-6-of-8/
The one cool and interesting thing about non-returning function
On Fri, 22 Oct 2010 13:22:19 -0400, Stewart Gordon
wrote:
On 22/10/2010 03:44, Rainer Deyke wrote:
A 'void' function returns, therefore it conceptually returns a value.
For generic programming, it is useful to treat 'void' as a type like any
other, except that it only has one possible value
On 25/10/2010 16:18, Steven Schveighoffer wrote:
I proposed earlier that maybe you shouldn't be able to create void
arrays directly. This would help with the "contains pointers" issue.
Indeed, void data is another issue here:
http://d.puremagic.com/issues/show_bug.cgi?id=679
Maybe we can com
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 up in things like assert's and enfo
.
Noreturn functions crop up in things like assert's and
enforce's. DMD internally hardcodes a few functions it knows
about that are noreturn, and the DMD optimizer and codegen take
advantage of it.
But when people write their own assert's and enforce's, this
falls apart. Whi
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 attribute rather than a pragma? It looks to
me that the goal is to pass information to the compiler, and
On 7/8/17 6:15 AM, Walter Bright wrote:
Has anyone a better idea? Does anyone want to write a DIP for this?
An attribute is fine. A more PL-minded possibility is to return a
specific type:
struct None
{
@disable this();
@disable this(this);
@disable @property None init();
}
None
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 attribute rather than a pragma?
So it's part of the summary of the fun
On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu
wrote:
On 7/8/17 6:15 AM, Walter Bright wrote:
Has anyone a better idea? Does anyone want to write a DIP for
this?
An attribute is fine. A more PL-minded possibility is to return
a specific type:
struct None
{
@disable this()
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
.
Noreturn functions crop up in things like assert's and
enforce's. DMD internally hardcodes a few functions it knows
about that are noreturn, and the DMD optimizer and codegen take
advantage of it.
But when people write their own assert's and enforce's, this
falls apart. Whi
On 07/08/2017 08:20 AM, Stefan Koch wrote:
... since it's going to be special cased by the compiler we might as
well hardwire a type called none.
Walter and I have repeated experience with moving compiler smarts into
library artifacts. Sometimes it's arguably not the best way to go, but
in th
On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote:
Why should this be an attribute rather than a pragma?
I agree. There's no reason I can think of as to why the no-return
should be part of the ABI.
On 07/08/2017 01:14 PM, Jack Stouffer wrote:
On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote:
Why should this be an attribute rather than a pragma?
I agree. There's no reason I can think of as to why the no-return should
be part of the ABI.
If present in the signature of the funct
On Saturday, 8 July 2017 at 17:14:32 UTC, Andrei Alexandrescu
wrote:
What is the signature of a function that logs something to a
file and ends in assert(0)?
I do get your point.
However I still doubt that this is worth a the additional
language complexity.
Usually the clue would be in t
On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu
wrote:
On 7/8/17 6:15 AM, Walter Bright wrote:
Has anyone a better idea? Does anyone want to write a DIP for
this?
An attribute is fine. A more PL-minded possibility is to return
a specific type:
struct None
{
@disable this()
On 7/8/17 2:26 PM, John Colvin wrote:
I wonder if some lessons from Haskell's "bottom" type would be relevant
here.
Affirmative. The nice touch of bottom (heh) is that it's convertible to
anything, so you can use it in complex expressions as a wildcard. -- Andrei
On 7/8/17 1:30 PM, Stefan Koch wrote:
On Saturday, 8 July 2017 at 17:14:32 UTC, Andrei Alexandrescu wrote:
What is the signature of a function that logs something to a file and
ends in assert(0)?
I do get your point.
However I still doubt that this is worth a the additional language
compl
On 7/8/2017 3:52 AM, Nicholas Wilson wrote:
consider that GDC and LDC already both have that attribute courtesy of their
backends (@attribute("noreturn") and @llvmAttr("noreturn") respectively).
One could argue that since "noreturn" changes the interface of a fu
ver return.
That is a scathingly brilliant idea. It has another nice effect - the compiler
doesn't have to diagnose:
@noreturn int foo();
as an error!
Me like.
anges the implementation of a function such
that it now returns, it will break any compiled code that relied on it being
noreturn.
This is why, for example, nothrow is part of the signature.
ot;) that the type None is impossible to create
> > and copy/move from a function, and therefore decrees the function
> > will never return.
>
> That is a scathingly brilliant idea. It has another nice effect - the
> compiler doesn't have to diagnose:
>
>@nor
t; everyone rolls their own None type with different names. An attribute
> has the advantage that it will be universally understood.
[...]
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 exc
On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu
wrote:
@disable @property None init();
You meant static here I guess.
The compiler detects (without having anything hardwired about
the particular type "None") that the type None is impossible to
create and copy/move from a fu
On Saturday, 8 July 2017 at 21:03:57 UTC, Vladimir Panteleev
wrote:
This particular one is countered by also adding a disabled
destructor.
Oops, never mind that - this makes the function uncallable.
On 7/8/2017 1:20 PM, H. S. Teoh via Digitalmars-d wrote:
Hmmm. Just to clarify, what exactly does @noreturn include? If I have a
function that calls exit(), that's @noreturn? What about a function that
always throws? Or a function that calls exec()? A function that always
ends in assert(
) that the type None is impossible to
create and copy/move from a function, and therefore decrees the
function will never return.
That's a lot more complex (for the compiler and to explain) than
using a simple magic @noreturn attribute.
Agreed that this is rarely needed but sometimes ni
On 7/8/2017 4:36 PM, Martin Nowak wrote:
That's a lot more complex (for the compiler and to explain) than using a simple
magic @noreturn attribute.
Agreed that this is rarely needed but sometimes nice to have. Far from being
important though ;).
We have types that cannot be named (Vold
; and call this type 'noreturn'.
noreturn functionFoo(bla-bla-bla);
On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote:
We have types that cannot be named (Voldemort types), types
that have no type (void), I suppose that types that cannot
exist will fill out the edge cases of the menagerie.
I assume there is a standard jargon for this - does anyone kn
On 7/8/2017 7:01 PM, sarn wrote:
On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote:
We have types that cannot be named (Voldemort types), types that have no type
(void), I suppose that types that cannot exist will fill out the edge cases of
the menagerie.
I assume there is a standar
cannot create
any instances of it. :-P From the POV of types as sets of possible
values, it's a type that corresponds with an empty set. However, then
we cannot distinguish between void (which is also by definition a type
that has no instances) and noreturn. I'm not sure how to interp
On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote:
(D already has a `void` type, so can't use Haskell's word.)
Just so we are all on the same page, from a type-theory
perspective void is a unit type (it has 1 value), not an
uninhabited type (it has no values, i.e. Haskell's _|_ (bot
On Sunday, 9 July 2017 at 04:23:15 UTC, Meta wrote:
On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote:
(D already has a `void` type, so can't use Haskell's word.)
Just so we are all on the same page, from a type-theory
perspective void is a unit type (it has 1 value), not an
uninha
On 07/08/2017 10:25 PM, Walter Bright wrote:
On 7/8/2017 7:01 PM, sarn wrote:
On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote:
We have types that cannot be named (Voldemort types), types that have
no type (void), I suppose that types that cannot exist will fill out
the edge cases o
On 07/08/2017 05:03 PM, Vladimir Panteleev wrote:
On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu wrote:
@disable @property None init();
You meant static here I guess.
The compiler detects (without having anything hardwired about the
particular type "None") that the type No
On 7/8/2017 9:23 PM, Meta wrote:
On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote:
(D already has a `void` type, so can't use Haskell's word.)
Just so we are all on the same page, from a type-theory perspective void is a
unit type (it has 1 value), not an uninhabited type (it has n
On 7/8/2017 9:32 PM, Meta wrote:
On Sunday, 9 July 2017 at 04:23:15 UTC, Meta wrote:
On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote:
(D already has a `void` type, so can't use Haskell's word.)
Just so we are all on the same page, from a type-theory perspective void is a
unit typ
On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
Has anyone a better idea?
What about
scope(exit) assert(0);
?
On 09.07.2017 07:44, Walter Bright wrote:
On 7/8/2017 9:32 PM, Meta wrote:
On Sunday, 9 July 2017 at 04:23:15 UTC, Meta wrote:
On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote:
(D already has a `void` type, so can't use Haskell's word.)
Just so we are all on the same page, from a
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 idea?
What about
scope(exit) assert(0);
?
void func()
out { assert(0); }
body
{
}
On Sunday, 9 July 2017 at 10:51:50 UTC, 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 idea?
What about
scope(exit) assert(0);
?
void func()
out { assert(0); }
body
{
}
Yes, this!
-
On Sunday, 9 July 2017 at 10:59:43 UTC, Steven Schveighoffer
wrote:
On Sunday, 9 July 2017 at 10:51:50 UTC, 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 idea?
What about
scope(exit) as
On 7/9/2017 3:48 AM, Timon Gehr wrote:
It is indeed incorrect, [...]
Thanks!
On 7/9/2017 3:31 AM, Mr.D wrote:
scope(exit) assert(0);
It needs to be part of the function signature, not the function implementation.
On 7/9/17 7:07 AM, Nicholas Wilson wrote:
On Sunday, 9 July 2017 at 10:59:43 UTC, Steven Schveighoffer wrote:
On Sunday, 9 July 2017 at 10:51:50 UTC, 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
ribute
is the simplest way to achieve the goals of:
* documentation, is doesn't get much simpler than @noreturn
* optimisation, its already in LDC and GDC, just under a
different name
* compatibility between compilers, its as simple as an alias in a
version statement per compiler.
On 7/9/17 1:36 AM, Walter Bright wrote:
If we wanted to be cute we could use `typeof()` to represent this type
as there is no value you can give to typeof such that it returns the
bottom type. It also avoids having to come up with some special symbol
or name for it.
That is indeed an intere
On 7/9/17 7:26 AM, Steven Schveighoffer wrote:
On 7/9/17 7:07 AM, Nicholas Wilson wrote:
On Sunday, 9 July 2017 at 10:59:43 UTC, Steven Schveighoffer wrote:
On Sunday, 9 July 2017 at 10:51:50 UTC, Daniel N wrote:
On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote:
On Saturday, 8 July 2017 at
On Sunday, 9 July 2017 at 13:13:28 UTC, Andrei Alexandrescu wrote:
On 7/9/17 1:36 AM, Walter Bright wrote:
If we wanted to be cute we could use `typeof()` to represent
this type as there is no value you can give to typeof such
that it returns the bottom type. It also avoids having to
come up
On 7/9/17 9:16 AM, Andrei Alexandrescu wrote:
I wonder why there's so much attraction to exotic approaches when
encoding "no return" with types has so much established theory and
practice with it. -- Andrei
Your definition of exotic differs from mine.
I haven't seen another solution other
1 - 100 of 235 matches
Mail list logo
