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

== 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.
> 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.

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

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

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.
<snip>

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.

== 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?
> 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);

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.

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.

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

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?
<snip>

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.