"Walter" <newshound@digitalmars.com> wrote in message news:cdjknj$1nef$1@digitaldaemon.com...
>
> "Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cdjimt$1mfr$1@digitaldaemon.com...
> > So you are saying that it is legal for an "int" function not to return
an
> > int, but it has to have atleast one return even though it might be
skiped
> > as int this example:
> >
> > int func()
> > {
> >      goto label;
> >      return 0;
> >      label:
> >      ;
> > }
>
> It is illegal to drop off the end without a return and to execute such a path.
>

But this function compiles and causes assert, so it basicaly does the same as if there wasn't a return, but the compiler is quite happy accepting it although it is invalid code. Here the compiler is tricked to accept the code that can't work, and it doesn't sound too good to me to trick the compiler.

I would more like to trust your compiler to report these errors than to
trust any tricks. BTW isn't it a bit silly that the compiler forses us to
have
a return and it is happy even though the return is placed in a ridicolous
or unreachable place?


PS. I'm going to the sea tomorow, and i'm looking forward to seeing
0.96 (or some bigger number) when i get back :)

"Ivan Senji" <ivan.senji@public.srce.hr> wrote in message news:cdk0up$1sun$1@digitaldaemon.com...
> But this function compiles and causes assert, so it basicaly does the same as if there wasn't a return, but the compiler is quite happy accepting it although it is invalid code. Here the compiler is tricked to accept the
code
> that can't work, and it doesn't sound too good to me to trick the
compiler.
>
> I would more like to trust your compiler to report these errors than to
> trust any tricks. BTW isn't it a bit silly that the compiler forses us to
> have
> a return and it is happy even though the return is placed in a ridicolous
> or unreachable place?

As far as the language spec is concerned, it doesn't matter if illegal code is caught at compile time or run time. I don't see the runtime check as being a trick.

In article <cdk0up$1sun$1@digitaldaemon.com>, Ivan Senji says...
>
>PS. I'm going to the sea tomorow, and i'm looking forward to seeing
>0.96 (or some bigger number) when i get back :)

In Valen's name!

You don't watch Babylon 5 do you? To a Minbari, "going to the sea" is a euphamism for dying. Coming back again afterwards would definitely elevate you a most exalted status.

Jill

PS. Sorry. Off topic post - but I couldn't resist it.

Stewart Gordon wrote:

>
> Requiring either a return or an assert(false) is even neater IMO, as it would then be easy to pinpoint the missing return, and would force the user to check whether it really is an error or a can't happen.
>
> Stewart.


Agreed!  I don't see why all D compiles shouldn't have flow analysis as mandatory.  This really is just a way of telling the compiler exactly what you mean.  Early detection will save much time.  You don't want someone else coming to you half an hour latter telling you that you've broken code only to find out you could of fixed it in a few seconds.

Come on, Walter, you can't say that an assert is as good as a compile time error.  The only valid excuse I can see is Walter making is that it is:
- Its a difficult check to perform

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

<snip>
> Agreed!  I don't see why all D compiles shouldn't have flow analysis as mandatory. 
<snip>

It would be very difficult, if not impossible, to determine at compile-time whether a particular path will acutally ever be executed. I think we'd need to solve the halting problem before it can be done perfectly.

It is, however, simple to determine which parts of a function are structurally reachable, as C/C++ compilers manage.  For example,

    import std.c.stdlib;

    int qwert(int yuiop) {
        if (abs(yuiop) + 1 > 0) return yuiop;
    }

Obviously this is always true, and so the end of the function would never be reached.  However, the compiler can't be absolutely sure of this; the structure of the function (as opposed to the actual behaviour) leaves the end open.  Hence the compiler would catch this as an error.

OTOH, if a function were defined by

    int asdfg(int yuiop) {
        if (abs(yuiop) + 1 > 0) {
            return yuiop;
        } else {
            return -1;
        }
    }

then all paths through the structure of the program have returns, and so the end is structurally unreachable.  And so no error would be flagged.

A literal assert(false) or thrown exception would be treated as a return in this respect.  At least before you get to catch blocks within the function being inspected....

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> J Anderson wrote:
>
> <snip>
>
>> Agreed!  I don't see why all D compiles shouldn't have flow analysis as mandatory. 
>
> <snip>
>
> It would be very difficult, if not impossible, to determine at compile-time whether a particular path will acutally ever be executed. I think we'd need to solve the halting problem before it can be done perfectly.
>
<snip>

I think that all paths should have a mandatory return or assert in them whether the user likes one where or not.  The compiler is not looking for paths that can be skipped.  It should require them on all paths as in:

int func()
{
  if (x)
  {
          while (something)
           {
                  return x;
            }

            //To fix the error message you'd need an assert here
   }
   else
   {
         return 0;
    }

     //or here
}

This type of analysis is reasonably simple.


-- 
-Anderson: http://badmama.com.au/~anderson/

In article <cdtk83$so5$1@digitaldaemon.com>, J Anderson says...

>I think that all paths should have a mandatory return or assert in them

Assuming that where you wrote "assert" you actually meant "throw", I'd agree with you and support this one. "assert", of course, is /itself/ a flow control mechanism, with

#    assert(x);

being roughly equivalent to:

#    debug
#    {
#        if (!(x))
#        {
#            throw new AssertError("");
#        }
#        // don't forget this path
#    }
#    // or this one

Arcane Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cdl6ha$2e47$1@digitaldaemon.com...
> In article <cdk0up$1sun$1@digitaldaemon.com>, Ivan Senji says...
> >
> >PS. I'm going to the sea tomorow, and i'm looking forward to seeing
> >0.96 (or some bigger number) when i get back :)
>
> In Valen's name!
>
> You don't watch Babylon 5 do you?

I don't :)

> To a Minbari, "going to the sea" is a  euphamism for dying.

I didn't know this! I'm sorry but i really don't know how to say that in English :)

> Coming back again afterwards would definitely elevate you a most exalted status.
>
> Jill
>
> PS. Sorry. Off topic post - but I couldn't resist it.
>
>

Ivan Senji wrote:
> "Arcane Jill" <Arcane_member@pathlink.com> wrote in message
> news:cdl6ha$2e47$1@digitaldaemon.com...
> 
>>In article <cdk0up$1sun$1@digitaldaemon.com>, Ivan Senji says...
>>
>>>PS. I'm going to the sea tomorow, and i'm looking forward to seeing
>>>0.96 (or some bigger number) when i get back :)
>>
>>In Valen's name!
>>
>>You don't watch Babylon 5 do you?
> 
> 
> I don't :)
> 
> 
>>To a Minbari, "going to the sea" is a  euphamism for dying.
> 
> 
> I didn't know this! I'm sorry but i really don't know how to say that in
> English :)

Perhaps if you specify the particular body of water, the Minbari won't be worried about you. ;)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/