In article <cditbh$1c4m$1@digitaldaemon.com>, Arcane Jill says...

Only in D could you do this!

#    void main()
#    {
#        return;
#        printf("hello world\n");
#    }

Jill

(PS. This is a minimal code example. Actual bugs in real code would obviously be more complicated than this).

"Derek Parnell" <derek@psych.ward> wrote in message news:cdil05$18sv$1@digitaldaemon.com...
> On Tue, 20 Jul 2004 18:17:28 +1000, Matthew wrote:
>
> > "Derek Parnell" <derek@psych.ward> wrote in message news:cdik17$18ej$1@digitaldaemon.com...
> >> On Tue, 20 Jul 2004 07:39:38 +0000 (UTC), Arcane Jill wrote:
> >>
> >>> Trimmed this one down to the absolute minimum
> >>>
> >>> #    int f()
> >>> #    {
> >>> #        throw new Error("");
> >>> #    }
> >>>
> >>> Currently this is a compile error:
> >>> auto.d(2): function f function expected to return a value of type int
> >>>
> >>> But it shouldn't be (and wouldn't be in C++). The function should only
> > be
> >>> "expected to return a value of type int" /if it actually returns/. If
> > you exit
> >>> via an exception, you don't need to return anything.
> >>>
> >>> Arcane Jill
> >>
> >> Jill, this is just silly. If one is going to write a routine that ...
> >>
> >> (a) says it will return something "int f()", and
> >> (b) deliberately *never* returns something,
> >>
> >> then you just have to wear the compiler message.
> >
> > Although I think Dereks' being simplistic - since after all one might
write
> > a function such as that shown below - I still agree with his sentiment.
I
> > never write code that precipitates such responses from the compiler, and voila, I never get those responses. Now I'm not saying you're wrong, but
I
> > think issues such as this should be on the back of the queue.
> >
> > A less dismissable example would be as follows:
> >
> > double sqrt(double d)
> > {
> >     if(d >= 0)
> >     {
> >         return . . .;
> >     }
> >
> >     throw Error();
> > }
> >
> > I'd never write this code, since I'd always want to explicitly deal with
the
> > erroneous parameters first, and I'd suggest that's a better style all
round.
>
> Actually, your code will compile (once the syntax is cleaned up). What I meant by " *never* returns something" was that under no circumstance will the routine ever return a value. In your example, it will return a value under some circumstances, but Jill's example will literally never return anything. That is the silly part.

I knew what you meant. :)

"Derek Parnell" <derek@psych.ward> wrote in message news:cdio37$1a87$1@digitaldaemon.com...
> On Tue, 20 Jul 2004 08:52:32 +0000 (UTC), Arcane Jill wrote:
>
> > In article <cdik17$18ej$1@digitaldaemon.com>, Derek Parnell says...
> >>Jill, this is just silly. If one is going to write a routine that ...
> >>
> >>(a) says it will return something "int f()", and
> >>(b) deliberately *never* returns something,
> >>
> >>then you just have to wear the compiler message.
> >
> > <Sigh>. Well, so much for paring things down to the absolute minimum.
Okay then,
> > a slightly longer example:
> >
> > #    class A
> > #    {
> > #        override int opCmp(Object o)
> > #        {
> > #            assert(false); // class A not comparable
> > #        }
> > #    }
> >
> > You don't have much choice about declaring a return type, because that's declared in the base class and you want the polymorphism to work.
> >
> > Jill
> >
> > PS. In the above example, the assert disappears in a release build,
giving a
> > different flow of execution (and a genuine compile error) from that of a
debug
> > build. Using throw gives a consistent flow of execution.
>
> Ok, we have a different coding style. I would have done something like this...
>
> # class A
> # {
> #   override int opCmp(Object o)
> #     {
> #         assert(false); // class A not comparable
> #         throw new Error("class A not comparable");
> #         return 0;
> #     }
> # }

That's a lot more obvious, and maintainable.

"Cabal" <cabalN05P4M@myrealbox.com> wrote in message news:cdiklu$18c7$1@digitaldaemon.com...
> As much as it pains me :) I have to agree with Matthew. There's a whole
list
> of other stuff to get working properly before this could be upgraded from 'niggle' to 'issue'.

So you're not going to be fighting through the crowds in the bookshop in September?

Sigh, I'll have to ring AWL and tell them to cut down the print run.

In article <cditku$1cah$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <cditbh$1c4m$1@digitaldaemon.com>, Arcane Jill says...
>
>Only in D could you do this!
>
>#    void main()
>#    {
>#        return;
>#        printf("hello world\n");
>#    }
>
>Jill
>
>(PS. This is a minimal code example. Actual bugs in real code would obviously be more complicated than this).

Calm down, Jill. This is not exactly a bug. Typical C/C++ compiler would issue a
warning saying "Unreachable code" in this case or "Not all control paths return
a value" in your previous example. Fixing this kind of behaviour now
is not really needed, while there are lots of other (serious) bugs floating
around.

P.S. Never had bugs in code because of misplaced return. Dunno why...

"Takuan" <Takuan_member@pathlink.com> wrote in message news:cdj0cg$1dcj$1@digitaldaemon.com...
> In article <cditku$1cah$1@digitaldaemon.com>, Arcane Jill says...
> >
> >In article <cditbh$1c4m$1@digitaldaemon.com>, Arcane Jill says...
> >
> >Only in D could you do this!
> >
> >#    void main()
> >#    {
> >#        return;
> >#        printf("hello world\n");
> >#    }
> >
> >Jill
> >
> >(PS. This is a minimal code example. Actual bugs in real code would
obviously be
> >more complicated than this).
>
> Calm down, Jill. This is not exactly a bug. Typical C/C++ compiler would
issue a
> warning saying "Unreachable code" in this case or "Not all control paths
return
> a value" in your previous example. Fixing this kind of behaviour now is not really needed, while there are lots of other (serious) bugs
floating
> around.
>
> P.S. Never had bugs in code because of misplaced return. Dunno why...

I had such a bug, and it wasn't that easy to find it!

I agree with Arcane Jill, Code after return or throw in a block should be an error, but there is time for this, because there are more important open ishues!

In article <cdj0cg$1dcj$1@digitaldaemon.com>, Takuan says...

>Calm down, Jill.

I've been calm all along, thank you very much, and it is perhaps a little disingenuous of you to imply otherwise.


>This is not exactly a bug. Typical C/C++ compiler would issue a
>warning saying "Unreachable code" in this case or "Not all control paths return
>a value" in your previous example.

Fair enough. Guess I've been using "treat warnings as errors" for too long.


>Fixing this kind of behaviour now
>is not really needed, while there are lots of other (serious) bugs floating
>around.

I agree. However, I find the comment irrelevant. If I have understood you correctly.... we shouldn't post bugs here which are less serious than those already in the queue. Is that right?

I'm sure Walter would prefer that they be reported than not, even if they are trivial, and that the bugs forum is the correct place to report them. I'm not aware of a dictat that says "don't report low priority bugs". Do correct me if I'm wrong.

Jill

Christ no! I'll buy the other 50% of the run :)
When you aren't being all religious you seem to know a fair old bit about
D...

> So you're not going to be fighting through the crowds in the bookshop in September?
> 
> Sigh, I'll have to ring AWL and tell them to cut down the print run.

Arcane Jill wrote:

>In article <cdj0cg$1dcj$1@digitaldaemon.com>, Takuan says...
>
>  
>
>>Calm down, Jill.
>>    
>>
>
>I've been calm all along, thank you very much, and it is perhaps a little
>disingenuous of you to imply otherwise.
>
>
>  
>
>>This is not exactly a bug. Typical C/C++ compiler would issue a
>>warning saying "Unreachable code" in this case or "Not all control paths return
>>a value" in your previous example.
>>    
>>
>
>Fair enough. Guess I've been using "treat warnings as errors" for too long.
>
>
>  
>
>>Fixing this kind of behaviour now
>>is not really needed, while there are lots of other (serious) bugs floating
>>around.
>>    
>>
>
>I agree. However, I find the comment irrelevant. If I have understood you
>correctly.... we shouldn't post bugs here which are less serious than those
>already in the queue. Is that right?
>
>I'm sure Walter would prefer that they be reported than not, even if they are
>trivial, and that the bugs forum is the correct place to report them. I'm not
>aware of a dictat that says "don't report low priority bugs". Do correct me if
>I'm wrong.
>
>Jill
>
>  
>

I think the argument here is that this type of problem is something that can easily be added at anytime, and has is essentially a semantic bug.   Syntactical bugs that cause dmd to not finish or cause the program to crash (directly) are probably seen as more trouble some since people have already learned to live with this in C++.

No harm ins suggesting it.  That's what the D newsgroups are for.  I see this as more of a feature request (ie for more strict syntax) rather then a bug which is kinda the other groups realm.  I agree that more C++ warnings should be made into D errors.


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

In article <cdii7q$17p3$1@digitaldaemon.com>, Arcane Jill says...
>
>Trimmed this one down to the absolute minimum
>
>#    int f()
>#    {
>#        throw new Error("");
>#    }
>
>Currently this is a compile error:
>auto.d(2): function f function expected to return a value of type int
>
>But it shouldn't be (and wouldn't be in C++). The function should only be "expected to return a value of type int" /if it actually returns/. If you exit via an exception, you don't need to return anything.
>
>Arcane Jill

(I'm trying to be helpful. Really, I am.)

The reason why people might want to comment on this "bug report" is that the compiler is enforcing the specification:

"At least one return statement is required if the function specifies a return type that is not void." (http://www.digitalmars.com/d/statement.html#return)

If the compiler is following the spec, it seems more like a *feature request* than a bug. I think if you want to discuss this issue, it should be in the digitalmars.D group. Feel free to disagree. Discuss it in the D.gnu group or digitalmars.D.dtl if you like. Whatever. It's your decision.

jcc7