Should also fix the return values of regular D programs sometime...

Like:
void main() {}
creal main() { return 0.0 + 0.0i; }
char[] main() { return "madness and mayhem"; }

IMNSHO; Another small thing that *must* be changed, before D 1.0 ?

http://www.digitalmars.com/d/archives/digitalmars/D/13127.html
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2677
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2853

--anders

Anders F Björklund wrote:
> Should also fix the return values of regular D programs sometime...
> 
> Like:
> void main() {}
> creal main() { return 0.0 + 0.0i; }
> char[] main() { return "madness and mayhem"; }
> 
> IMNSHO; Another small thing that *must* be changed, before D 1.0 ?
<snip>

Yes.  And while we're at it, define what exit code'll be returned if the program exits by an exception.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> Yes.  And while we're at it, define what exit code'll be returned if the program exits by an exception.

I think that void main() {} should return 0,
and that such an exception should return a 1.

This would work nice for unittests, for instance ?

--anders

Anders F Björklund wrote:
> Should also fix the return values of regular D programs sometime...
> 
> Like:
> void main() {}
> creal main() { return 0.0 + 0.0i; }
> char[] main() { return "madness and mayhem"; }
> 
> IMNSHO; Another small thing that *must* be changed, before D 1.0 ?
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/13127.html
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2677
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/2853
> 
> --anders

I've added these to the 'Pending Peeves' page on the wiki, and I also put a ShowStoppers list. IMHO, this one's a bug rather than a showstopper. (By showstopper, I mean, things where anyone who reads through the spec will say, "this language is definitely not at 1.0").

Don Clugston wrote:

> I've added these to the 'Pending Peeves' page on the wiki, and I also put a ShowStoppers list. IMHO, this one's a bug rather than a showstopper. (By showstopper, I mean, things where anyone who reads through the spec will say, "this language is definitely not at 1.0").

Right, I didn't really mean ShowStopper for this one, but more like:
"if this isn't fixed by the time that D 1.0 is finalized/released,
then we will just have to live with it being broken". Like C has to ?

e.g. http://users.aber.ac.uk/auj/voidmain.shtml

--anders

Don Clugston wrote:
<snip>
> I've added these to the 'Pending Peeves' page on the wiki, and I also put a ShowStoppers list. IMHO, this one's a bug rather than a showstopper. (By showstopper, I mean, things where anyone who reads through the spec will say, "this language is definitely not at 1.0").

The whole page was designed to be something like a list of showstoppers for 1.0.  Did you actually look through the list before you doubled these two out?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Don Clugston wrote:
> <snip>
> 
>> I've added these to the 'Pending Peeves' page on the wiki, and I also put a ShowStoppers list. IMHO, this one's a bug rather than a showstopper. (By showstopper, I mean, things where anyone who reads through the spec will say, "this language is definitely not at 1.0").
> 
> 
> The whole page was designed to be something like a list of showstoppers for 1.0.  Did you actually look through the list before you doubled these two out?

Yes, I did. (The errors going to stderr was already there, I didn't see the others). Many of the peeves look to me as though they are bugs or QOI issues with DMD, (eg, some don't apply to gdc). I think that an obvious 1.0 requirement is that "the number of known severe bugs in the compiler is small", but the pending peeves lists is certainly not exhaustive, and we expect any new ones to be fixed in bugfix releases.

It just seems to me that there is a distinct category of things (quite small) where if a D 1.0 release is made, people will laugh. I don't think we can even talk about a 1.0 release while the spec still has [blah, blah, blah] in it. (Whereas I think it's OK to say, array operations will be a 2.0 feature).
Probably some of the existing things on the list also fall in that category. Personally, I would hope that everything on the list be addressed before 1.0, but I suspect that (for example) array operations will not be. And I know that DMD 1.0 will still have bugs.

Anyway (a) you made that page; and (b) it's a wiki, so if you don't like that categorisation, change it. At least, the wording wasn't clear enough to me to understand the rationale. There doesn't seem to be category for things which Walter has agreed to change, but which don't yet appear in either DMD or in the spec.

Don Clugston wrote:
<snip>
> Yes, I did. (The errors going to stderr was already there, I didn't see the others). Many of the peeves look to me as though they are bugs or QOI issues with DMD, (eg, some don't apply to gdc). I think that an obvious 1.0 requirement is that "the number of known severe bugs in the compiler is small", but the pending peeves lists is certainly not exhaustive, and we expect any new ones to be fixed in bugfix releases.

And that the spec is well-defined.

> It just seems to me that there is a distinct category of things (quite small) where if a D 1.0 release is made, people will laugh. I don't think we can even talk about a 1.0 release while the spec still has [blah, blah, blah] in it. (Whereas I think it's OK to say, array operations will be a 2.0 feature).

But it's not OK to leave it in all its glory in the current spec at the same time.

> Probably some of the existing things on the list also fall in that category. Personally, I would hope that everything on the list be addressed before 1.0, but I suspect that (for example) array operations will not be. And I know that DMD 1.0 will still have bugs.
> 
> Anyway (a) you made that page; and (b) it's a wiki, so if you don't like that categorisation, change it.

When I can think of what to change it to....

> At least, the wording wasn't clear enough to me to understand the rationale. There doesn't seem to be category for things which Walter has agreed to change, but which don't yet appear in either DMD or in the spec.

Examples?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Don Clugston wrote:
> <snip>
> 
>> Yes, I did. (The errors going to stderr was already there, I didn't see the others). Many of the peeves look to me as though they are bugs or QOI issues with DMD, (eg, some don't apply to gdc). I think that an obvious 1.0 requirement is that "the number of known severe bugs in the compiler is small", but the pending peeves lists is certainly not exhaustive, and we expect any new ones to be fixed in bugfix releases.
> 
> And that the spec is well-defined.

Right. Again, we can expect "bugfixes" to be made to the spec post-1.0.

>> There doesn't seem to be category for things which Walter has agreed to change, but which don't yet appear in either DMD or in the spec.
> 
> Examples?
* Stack based classes -- the future meaning of the 'auto' keyword.
* Removing the implicit conversion real->creal and ireal->creal.
And maybe we could add, do the "Future Directions" all refer to post-1.0 features?

That first one is very important! We need to know if it is 1.0 feature or not.
You're right about the array operations. Are they not implemented in D 1.0, or are they just not yet implemented in DMD?

Maybe I was just thrown off by the name "Pending Peeves". To me, that implies bugs or language misfeatures which you are having to work around. Whereas a 'to do for 1.0' to me includes things that don't affect anyone, but which need to be done for completeness. (Like the array ops, which we know are unavailable now, but we also know will happen some day, the only uncertain thing is what the compiler number will be when they are available).