www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - noreturn property

reply Iain Buclaw <ibuclaw ubuntu.com> writes:
A few standard library functions, such as 'abort' and 'exit', cannot return.
However there is no way in DMD to let the 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 to return.

Example:

 noreturn void fatal()
{
    print("Error");
    exit(1);
}

The 'noreturn' keyword would tell the compiler that 'fatal' cannot return, and
can then optimise without regard to what would happen if 'fatal' ever did
return. This should also allow fatal to be used instead of a return or assert
statement.

Example:

int mycheck(int x)
{
    if (x > 1)
        return OK;
    fatal();
}


Thoughts?
Oct 21 2010
next sibling parent Bernard Helyer <b.helyer gmail.com> writes:
 Thoughts?



I really, really like the idea.
Oct 21 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Oct 21 2010
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 21 Oct 2010 11:54:26 +0000, Iain Buclaw wrote:


 A few standard library functions, such as 'abort' and 'exit', cannot
 return. However there is no way in DMD to let the 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 to return.
 
 Example:
 
  noreturn void fatal()
 {
     print("Error");
     exit(1);
 }
 
 The 'noreturn' keyword would tell the compiler that 'fatal' cannot
 return, and can then optimise without regard to what would happen if
 'fatal' ever did return. This should also allow fatal to be used instead
 of a return or assert statement.
 
 Example:
 
 int mycheck(int x)
 {
     if (x > 1)
         return OK;
     fatal();
 }
 
 
 Thoughts?




It would be useful for std.exception.enforce(), as you could end a 
function with enforce(false).

-Lars
Oct 21 2010
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 21 Oct 2010 08:52:35 -0400, Lars T. Kyllingstad  
<public kyllingen.nospamnet> wrote:


 On Thu, 21 Oct 2010 11:54:26 +0000, Iain Buclaw wrote:


 A few standard library functions, such as 'abort' and 'exit', cannot
 return. However there is no way in DMD to let the 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 to return.

 Example:

  noreturn void fatal()
 {
     print("Error");
     exit(1);
 }

 The 'noreturn' keyword would tell the compiler that 'fatal' cannot
 return, and can then optimise without regard to what would happen if
 'fatal' ever did return. This should also allow fatal to be used instead
 of a return or assert statement.

 Example:

 int mycheck(int x)
 {
     if (x > 1)
         return OK;
     fatal();
 }


 Thoughts?




 It would be useful for std.exception.enforce(), as you could end a
 function with enforce(false).



1. It doesn't work that way.  The function has to *never* return, no  
matter what the arguments.
2. assert(false) already does this.

-Steve
Oct 21 2010
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Thu, 21 Oct 2010 09:14:01 -0400, Steven Schveighoffer wrote:


 On Thu, 21 Oct 2010 08:52:35 -0400, Lars T. Kyllingstad
 <public kyllingen.nospamnet> wrote:
 

 On Thu, 21 Oct 2010 11:54:26 +0000, Iain Buclaw wrote:


 A few standard library functions, such as 'abort' and 'exit', cannot
 return. However there is no way in DMD to let the 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 to return.

 Example:

  noreturn void fatal()
 {
     print("Error");
     exit(1);
 }

 The 'noreturn' keyword would tell the compiler that 'fatal' cannot
 return, and can then optimise without regard to what would happen if
 'fatal' ever did return. This should also allow fatal to be used
 instead of a return or assert statement.

 Example:

 int mycheck(int x)
 {
     if (x > 1)
         return OK;
     fatal();
 }


 Thoughts?




 It would be useful for std.exception.enforce(), as you could end a
 function with enforce(false).



 1. It doesn't work that way.  The function has to *never* return, no
 matter what the arguments.



Ah, of course. :)



 2. assert(false) already does this.



Except that assert(false) throws an Error (or issues a HLT in release 
mode), while enforce(false) throws an Exception.

But you are absolutely right, it won't work anyway, so I guess I'll just 
have to suck it up and write 'throw new Exception'... :)

-Lars
Oct 21 2010
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Lars T. Kyllingstad (public kyllingen.NOSPAMnet)'s article

 On Thu, 21 Oct 2010 11:54:26 +0000, Iain Buclaw wrote:

 A few standard library functions, such as 'abort' and 'exit', cannot
 return. However there is no way in DMD to let the 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 to return.

 Example:

  noreturn void fatal()
 {
     print("Error");
     exit(1);
 }

 The 'noreturn' keyword would tell the compiler that 'fatal' cannot
 return, and can then optimise without regard to what would happen if
 'fatal' ever did return. This should also allow fatal to be used instead
 of a return or assert statement.

 Example:

 int mycheck(int x)
 {
     if (x > 1)
         return OK;
     fatal();
 }


 Thoughts?



 function with enforce(false).
 -Lars



Or with any of the helper functions in core.exception, for that matter; such as
onOutOfMemoryError().

Regards
Iain
Oct 21 2010
prev sibling next sibling parent Justin Johansson <no spam.com> writes:
On 21/10/2010 10:54 PM, Iain Buclaw wrote:

 A few standard library functions, such as 'abort' and 'exit', cannot return.
 However there is no way in DMD to let the 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 to return.

 Example:

  noreturn void fatal()
 {
      print("Error");
      exit(1);
 }

 The 'noreturn' keyword would tell the compiler that 'fatal' cannot return, and
 can then optimise without regard to what would happen if 'fatal' ever did
 return. This should also allow fatal to be used instead of a return or assert
 statement.



Yes, well, and while others may say that I must be drunk to
suggest so, the problem lies in the D type system, albeit,
the lack thereof.

Further, I know that my previous "canoe" joke did not go down
very well or was not understood by the wider D community.

Thankfully questions posed by your post give credence to
my prior "joke" about the D type system lacking a formal
substance (i.e. being close to water).

There is a good answer awaiting but it is not a hack such
as  noreturn.

Cheers
Justin Johansson
Oct 21 2010
prev sibling next sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Iain Buclaw, el 21 de octubre a las 11:54 me escribiste:

 A few standard library functions, such as 'abort' and 'exit', cannot return.
 However there is no way in DMD to let the 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 to return.
 
 Example:
 
  noreturn void fatal()
 {
     print("Error");
     exit(1);
 }
 
 The 'noreturn' keyword would tell the compiler that 'fatal' cannot return, and
 can then optimise without regard to what would happen if 'fatal' ever did
 return. This should also allow fatal to be used instead of a return or assert
 statement.
 
 Example:
 
 int mycheck(int x)
 {
     if (x > 1)
         return OK;
     fatal();
 }
 
 
 Thoughts?



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");
     exit(1);
}

?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
The world's best known word is "okay"
The second most well-known word is "Coca-Cola"
Oct 21 2010
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Leandro Lucarella schrieb:

 Iain Buclaw, el 21 de octubre a las 11:54 me escribiste:

 A few standard library functions, such as 'abort' and 'exit', cannot return.
 However there is no way in DMD to let the 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 to return.

 Example:

  noreturn void fatal()
 {
     print("Error");
     exit(1);
 }

 The 'noreturn' keyword would tell the compiler that 'fatal' cannot return, and
 can then optimise without regard to what would happen if 'fatal' ever did
 return. This should also allow fatal to be used instead of a return or assert
 statement.

 Example:

 int mycheck(int x)
 {
     if (x > 1)
         return OK;
     fatal();
 }


 Thoughts?



 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");
      exit(1);
 }
 
 ?
 



Obviously he wants a portable way to do this that will work on any up-to-date
D2 compiler.. doesn't 
make much sense to have a gdc-only solution that makes code incompatible with
dmd (and possibly 
other compilers). Of course one may use version(GDC) or something like that to
ensure compatibility, 
but that's just ugly.

Cheers,
- Daniel
Oct 21 2010
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Daniel Gibson (metalcaedes gmail.com)'s article

 Leandro Lucarella schrieb:

 Iain Buclaw, el 21 de octubre a las 11:54 me escribiste:

 A few standard library functions, such as 'abort' and 'exit', cannot return.
 However there is no way in DMD to let the 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 to return.

 Example:

  noreturn void fatal()
 {
     print("Error");
     exit(1);
 }

 The 'noreturn' keyword would tell the compiler that 'fatal' cannot return, and
 can then optimise without regard to what would happen if 'fatal' ever did
 return. This should also allow fatal to be used instead of a return or assert
 statement.

 Example:

 int mycheck(int x)
 {
     if (x > 1)
         return OK;
     fatal();
 }


 Thoughts?



 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");
      exit(1);
 }

 ?







 make much sense to have a gdc-only solution that makes code incompatible with




 other compilers). Of course one may use version(GDC) or something like that to




 but that's just ugly.
 Cheers,
 - Daniel



The GNU_attribute pragmas are just hints to the GCC backend; very limited in
what
they do; don't really thrive very well in D's environment.

Take for example:

pragma (GNU_attribute, vector_size(16)) typedef int MyInt;

And you have a MyInt data type that is 16bytes wide, but D will still report
that
it is 4, and you can't use or assign anything to it either (else we'll ICE). I
guess it is a WIP feature that got left behind, I could have a look at it
improving it sometime, but I haven't really seen any benefits in reviving it
though...
Oct 21 2010
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Leandro Lucarella (luca llucax.com.ar)'s article

 Iain Buclaw, el 21 de octubre a las 11:54 me escribiste:

 A few standard library functions, such as 'abort' and 'exit', cannot return.
 However there is no way in DMD to let the 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 to return.

 Example:

  noreturn void fatal()
 {
     print("Error");
     exit(1);
 }

 The 'noreturn' keyword would tell the compiler that 'fatal' cannot return, and
 can then optimise without regard to what would happen if 'fatal' ever did
 return. This should also allow fatal to be used instead of a return or assert
 statement.

 Example:

 int mycheck(int x)
 {
     if (x > 1)
         return OK;
     fatal();
 }


 Thoughts?



 do in GDC using:
 pragma(GNU_attribute, noreturn)) void fatal()
 {
      print("Error");
      exit(1);
 }
 ?



No.

More to the truth, when merging the 2.031 frontend, I found myself having to put
in a lot of assert(0) or returns to satisfy several build errors in the EH
unwind
code for Dwarf2. Just seemed like a lot of redundant code to me really. Asked in
#d how useful such a property would be, then I got heckled to post here.
Oct 21 2010
prev sibling next sibling parent reply Ezneh <petitv.isat gmail.com> writes:
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" a returned value.


I think that could be great too.
Oct 21 2010
parent bearophile <bearophileHUGS lycos.com> writes:
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 languages I've sometimes seen a cast to void (at the call point) of
the return value:

cast(void)someFunction();

This silences the lint in some situations.

GNU C has the warn_unused_result that works in a different way, it makes the
compiler generate a warning at the call point if you don't use the result of a
function that has such attribute:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bwarn_005funused_005fresult_007d-attribute-2509

(Some of those attributes will probably be added to D2 as non-standard
extensions if they don't become standard features first.)

Bye,
bearophile
Oct 21 2010
prev sibling next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
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()
{
    print("Error");
    exit(1);
}

Here 'null_type' is a type that has no values, as opposed to 'void'
which has only one possible value.  No variables may be declared of type
'null_type'.  A function with a return type of 'null_type' never returns.

Either way would work (and this feature is definitely useful), but
'null_type' has some significant advantages:
  - It can be used in delegates and function pointers.
  - It can be used in generic code where you don't know if a function
will return or not.
  - It makes for more concise code.

Feel free to think of a better name than 'null_type'.


-- 
Rainer Deyke - rainerd eldwood.com
Oct 21 2010
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Rainer Deyke (rainerd eldwood.com)'s article

 On 10/21/2010 05:54, Iain Buclaw wrote:

  noreturn void fatal()
 {
     print("Error");
     exit(1);
 }
 Thoughts?



 doesn't.  I would prefer this:
 null_type fatal()
 {
     print("Error");
     exit(1);
 }
 Here 'null_type' is a type that has no values, as opposed to 'void'
 which has only one possible value.  No variables may be declared of type
 'null_type'.  A function with a return type of 'null_type' never returns.
 Either way would work (and this feature is definitely useful), but
 'null_type' has some significant advantages:
   - It can be used in delegates and function pointers.
   - It can be used in generic code where you don't know if a function
 will return or not.
   - It makes for more concise code.
 Feel free to think of a better name than 'null_type'.



Not sure what you mean when you say that void has only one possible value. To
me,
'void' for a function means something that does not return any value (or
result).
Are you perhaps confusing it with to, lets say an 'int' function that is marked
as
noreturn?

Regards
Iain
Oct 21 2010
parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 10/21/2010 11:37, Iain Buclaw wrote:

 Not sure what you mean when you say that void has only one possible value. To
me,
 'void' for a function means something that does not return any 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 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).  If this is not implemented in
D at the moment, it should be.

auto callFunction(F)(F f) {
  return f();
}

void f() {
}

callFunction(&f);


-- 
Rainer Deyke - rainerd eldwood.com
Oct 21 2010
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Rainer Deyke (rainerd eldwood.com)'s article

 On 10/21/2010 11:37, Iain Buclaw wrote:

 Not sure what you mean when you say that void has only one possible value. To
me,
 'void' for a function means something that does not return any value (or
result).
 Are you perhaps confusing it with to, lets say an 'int' function that is
marked as
 noreturn?



 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).  If this is not implemented in
 D at the moment, it should be.
 auto callFunction(F)(F f) {
   return f();
 }
 void f() {
 }
 callFunction(&f);



Oh, I get you. If I were to go along with your null_type idea then, I guess
'volatile' would be as good as any keyword/type to say that this function does
not
return.
Oct 22 2010
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 22/10/2010 03:44, Rainer Deyke wrote:
<snip>

 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).  If this is not implemented in
 D at the moment, it should be.



I've sometimes thought about this, and felt in any case that void.sizeof 
ought to be 0.

The problem now is that it would clash with void array slicing and 
pointer arithmetic, which rely on the size of void being 1.

Stewart.
Oct 22 2010
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 25/10/2010 16:18, Steven Schveighoffer wrote:
<snip>

 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 combine that with your idea, and void * is simply a vehicle
 to pass untyped data, and you can only use it if you cast it to
 something else?




So effectively, you can't slice or take the length of a void[] or do 
arithmetic on void* - you have to cast it to something else first.  This 
would make sense.

But when it has two possible uses - as a container for untyped data and 
as a zero-length data type, are there generic programming difficulties?

Stewart.
Oct 25 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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 but is rarely of use and hardly a game changer.


Andrei
Oct 21 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 22 Oct 2010 13:22:19 -0400, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:


 On 22/10/2010 03:44, Rainer Deyke wrote:
 <snip>

 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).  If this is not implemented in
 D at the moment, it should be.



 I've sometimes thought about this, and felt in any case that void.sizeof  
 ought to be 0.

 The problem now is that it would clash with void array slicing and  
 pointer arithmetic, which rely on the size of void being 1.



I proposed earlier that maybe you shouldn't be able to create void arrays  
directly.  This would help with the "contains pointers" issue.  Maybe we  
can combine that with your idea, and void * is simply a vehicle to pass  
untyped data, and you can only use it if you cast it to something else?

It would require a *lot* of changes to the runtime, but it might be worth  
it.

-Steve
Oct 25 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
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");
     exit(1);
}

?



 Obviously he wants a portable way to do this that will work on any
 up-to-date D2 compiler.. doesn't make much sense to have a gdc-only
 solution that makes code incompatible with dmd (and possibly other
 compilers). Of course one may use version(GDC) or something like
 that to ensure compatibility, but that's just ugly.



Maybe it came out wrong, it wasn't my intention to make it sound like
a bad idea. On the contrary, I think is a good idea, and there are
plenty of other GCC attributes that worth having.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
PIRATAS DEL ASFALTO ROBAN CAMION CON POLLOS CONGELADOS...
	-- Crónica TV
Oct 21 2010
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message 
news:i9p9li$282u$1 digitalmars.com...

A few standard library functions, such as 'abort' and 'exit', cannot 
return.
 However there is no way in DMD to let the 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 to return.

 Example:

  noreturn void fatal()
 {
    print("Error");
    exit(1);
 }

 The 'noreturn' keyword would tell the compiler that 'fatal' cannot return, 
 and
 can then optimise without regard to what would happen if 'fatal' ever did
 return. This should also allow fatal to be used instead of a return or 
 assert
 statement.

 Example:

 int mycheck(int x)
 {
    if (x > 1)
        return OK;
    fatal();
 }


 Thoughts?



A while ago someone mentioned a feature that some languages have that's a 
specific that indicates "never returns". (I'll just call it type 
"noreturn").

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 " noreturn 
void foo()" isn't great since a "void" return value suggests that it at 
least returns.

So your "fatal" would be like this:

noreturn fatal()
{
   print("Error");
   exit(1);
}

And likewise, "exit" would be declared as "noreturn exit(int)" (otherwise 
the compiler would, presumably, complain that a "noreturn" function 
returns).

Since this "noreturn" would be an actual type, in the langauges that have 
it, it will often participate in arithmetic types, so you can have a 
function that may or may not return:

Arithmetic!(noreturn, int) foo(int num)
{
    if(num == 7)
        exit(1);
    else
        return num;
}

Or something like that anyway. (Although, AIUI, those languages generally 
have arithmetic types built into the langauge itself.)
Oct 21 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
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 " noreturn 
 void foo()" isn't great since a "void" return value suggests that it at 
 least returns.



I suggest to keep things simpler, minimize changes to other parts of D, and
avoid creating new keywords for this very minor feature, and allow only the
signature:
 noreturn void somefunctioname(...)

So this is an additive change to D2, and may be added later.

Bye,
bearophile
Oct 21 2010
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Leandro Lucarella (luca 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. For instance, with your " noreturn": " noreturn int foo()"
 would be legal, but wouldn't make any sence. And in a way, even " noreturn
 void foo()" isn't great since a "void" return value suggests that it at
 least returns.



 I suggest to keep things simpler, minimize changes to other parts of
 D, and avoid creating new keywords for this very minor feature, and
 allow only the signature:
  noreturn void somefunctioname(...)

 So this is an additive change to D2, and may be added later.



 a pragma. It would be nice to use a pragma that is understood by all the
 compilers (even when all the compilers should not be forced to take
 advantage of it). Same thing for inline and other GCC attributes that
 seems good for optimizations.



I see it as a little more than just an optimisation; also a way to tell the
compiler that the function you are calling should be treated as a halt statement
if found at the end of a function body (as assert(0) is).

Regards
Iain
Oct 21 2010
prev sibling next sibling parent Leandro Lucarella <luca llucax.com.ar> writes:
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()" 
 would be legal, but wouldn't make any sence. And in a way, even " noreturn 
 void foo()" isn't great since a "void" return value suggests that it at 
 least returns.



 I suggest to keep things simpler, minimize changes to other parts of
 D, and avoid creating new keywords for this very minor feature, and
 allow only the signature:
  noreturn void somefunctioname(...)
 
 So this is an additive change to D2, and may be added later.



Exactly, this is just an optimization, that's why for me is fine with
a pragma. It would be nice to use a pragma that is understood by all the
compilers (even when all the compilers should not be forced to take
advantage of it). Same thing for inline and other GCC attributes that
seems good for optimizations.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
JUGAR COMPULSIVAMENTE ES PERJUDICIAL PARA LA SALUD.
	-- Casino de Mar del Plata
Oct 21 2010
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 21/10/2010 12:54, Iain Buclaw wrote:
<snip>

  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 optimise without regard to what would happen if 'fatal' ever did
 return. This should also allow fatal to be used instead of a return or assert
 statement.




You'd normally use an exception for this, not an exit or assert.  Or 
have you a use case for forcing that no catching or cleanup will take place?

Stewart.
Oct 22 2010