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
>
> 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
On Thu, 21 Oct 2010 11:54:26 +, 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
On Thu, 21 Oct 2010 08:52:35 -0400, Lars T. Kyllingstad
wrote:
On Thu, 21 Oct 2010 11:54:26 +, 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 ei
== Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article
> On Thu, 21 Oct 2010 11:54:26 +, 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
On Thu, 21 Oct 2010 09:14:01 -0400, Steven Schveighoffer wrote:
> On Thu, 21 Oct 2010 08:52:35 -0400, Lars T. Kyllingstad
> wrote:
>
>> On Thu, 21 Oct 2010 11:54:26 +, Iain Buclaw wrote:
>>
>>> A few standard library functions, such as 'abort' and 'exit', cannot
>>> return. However there is
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 w
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"
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
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)' sta
== Quote from Leandro Lucarella (l...@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
== Quote from Daniel Gibson (metalcae...@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 kno
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()
{
print("Error");
exit(1);
}
Here 'null_type' i
== 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' returns type 'void', except that it
> doesn't. I would prefer this:
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");
> > exit(1);
> >}
> >
> >?
> >
>
> Obviously he wants a po
"Iain Buclaw" wrote in message
news:i9p9li$282...@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
>
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
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
== 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. For instance, with your "@noreturn": "@noreturn int foo(
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
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 optimise without regard to what would happen if 'fata
== Quote from Rainer Deyke (rain...@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 perh
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
30 matches
Mail list logo
