www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.027 and 2.011 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
A whole lotta library improvements.

http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.027.zip

http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.011.zip

I had planned on doing struct destructors for this update, but they are 
not done yet.
Feb 19 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fpf9bk$2upn$1 digitalmars.com...

A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they are 
 not done yet.


.tupleof can now access private fields of a struct/class

Any reason why this was fixed in D2 but not in D1?  My binding library is 
still broken because of it..
Feb 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 .tupleof can now access private fields of a struct/class
 
 Any reason why this was fixed in D2 but not in D1?  My binding library is 
 still broken because of it.. 


I guess that depends on if it's an enhancement or a bug fix. Obviously, 
you consider it the latter :-)
Feb 19 2008
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fpfco5$7j5$1 digitalmars.com...

 Jarrett Billingsley wrote:

 .tupleof can now access private fields of a struct/class

 Any reason why this was fixed in D2 but not in D1?  My binding library is 
 still broken because of it..


 I guess that depends on if it's an enhancement or a bug fix. Obviously, 
 you consider it the latter :-)


Obviously I do ;)  Especially since it's not mentioned anywhere in the spec.
Feb 19 2008
prev sibling next sibling parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Tue, 19 Feb 2008 21:06:31 +0200, Walter Bright <newshound1 digitalmars.com>
wrote:


 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they are
 not done yet.


That looks great! 
However, D1's Phobos did not get any of the fixes?

Also, it seems that bug 1815 doesn't belong in D1's changelog.

-- 
Best regards,
 Vladimir                          mailto:thecybershadow gmail.com
Feb 19 2008
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,


 A whole lotta library improvements.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip
 I had planned on doing struct destructors for this update, but they
 are not done yet.
 


Is there now some way to force dmd to output the link command?
Feb 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 Is there now some way to force dmd to output the link command?


-v
Feb 19 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Walter,


 BCS wrote:
 

 Is there now some way to force dmd to output the link command?
 


 -v
 


:)
Feb 19 2008
prev sibling parent Frank Benoit <keinfarbton googlemail.com> writes:
Walter Bright schrieb:

 BCS wrote:

 Is there now some way to force dmd to output the link command?


 
 -v
 


For me it still prints the gcc line.
I use dmd 1.027 on linux.
Feb 20 2008
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
Wow what a huge changelist for the std lib, awesome !

But i wonder about one thing:

[CODE]

class Foo {
   int foo() {
       synchronized(this){
           return 8;
       }
   }
}

[/CODE]

why does 2.011 in contrast to the previous 2.010 warn me with "warning - 
main.d(3): function main.Foo.foo no return at end of function" ? why is 
this a probem suddenly ? i have plenty of this warnings spit out in my 
project now ;(


Walter Bright schrieb:

 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they 
 are not done yet.
Feb 19 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Extrawurst wrote:

 Wow what a huge changelist for the std lib, awesome !
 
 But i wonder about one thing:
 
 [CODE]
 
 class Foo {
   int foo() {
       synchronized(this){
           return 8;
       }
   }
 }
 
 [/CODE]
 
 why does 2.011 in contrast to the previous 2.010 warn me with "warning - 
 main.d(3): function main.Foo.foo no return at end of function" ? why is 
 this a probem suddenly ? i have plenty of this warnings spit out in my 
 project now ;(


Because I reimplemented the flow analysis, and it looks like there's a 
bug in it :-(
Feb 19 2008
parent reply Extrawurst <spam extrawurst.org> writes:
Walter Bright schrieb:

 Extrawurst wrote:

 Wow what a huge changelist for the std lib, awesome !

 But i wonder about one thing:

 [CODE]

 class Foo {
   int foo() {
       synchronized(this){
           return 8;
       }
   }
 }

 [/CODE]

 why does 2.011 in contrast to the previous 2.010 warn me with 
 "warning - main.d(3): function main.Foo.foo no return at end of 
 function" ? why is this a probem suddenly ? i have plenty of this 
 warnings spit out in my project now ;(


 Because I reimplemented the flow analysis, and it looks like there's a 
 bug in it :-(


i made an entry in bugzilla
Feb 20 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Extrawurst wrote:

 i made an entry in bugzilla


Thank you.
Feb 20 2008
prev sibling next sibling parent reply "Saaa" <empty needmail.com> writes:
Is it possible to check how many known bugs are still unsolved for D1 ?
Feb 19 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Saaa wrote:

 Is it possible to check how many known bugs are still unsolved for D1 ? 


I think you can get that from bugzilla.
Feb 19 2008
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 A whole lotta library improvements.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip
 
 I had planned on doing struct destructors for this update, but they are 
 not done yet.


For all who care, Tango appears to compile with D1.027.

(It didn't compile with D1.026 -- some errors about "scope".
I tested with the SVN version of Tango with DMD.
I did not try the 0.99.4 "Frank" release, or GCD so I can't vouch for 
those.)

--bb
Feb 19 2008
prev sibling next sibling parent reply torhu <no spam.invalid> writes:
Walter Bright wrote:

 A whole lotta library improvements.


I had to copy and paste the 2.0 changelog into my editor to be able to 
even read it.  Would it be possible to get a readable font face and 
size? There is no shame in just using black text on a white background 
either. Please?

I use FF 2 on winxp, so I don't think I have a weird setup.  19 inch 
CRT, 1152x864. That's pretty mainstream, and the 1.0 docs look just fine 
on my screen.
Feb 19 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
torhu wrote:

 Walter Bright wrote:

 A whole lotta library improvements.


 
 I had to copy and paste the 2.0 changelog into my editor to be able to 
 even read it.  Would it be possible to get a readable font face and 
 size? There is no shame in just using black text on a white background 
 either. Please?
 
 I use FF 2 on winxp, so I don't think I have a weird setup.  19 inch 
 CRT, 1152x864. That's pretty mainstream, and the 1.0 docs look just fine 
 on my screen.


The font is pretty darned small over here too.  Also WinXP/FF2.  I 
wouldn't say unreadable, but the 1.0 changelog is definitely easier on 
the eyes.

I thought a web developer was helping you to make the D site more 
modern.  Is this the result of that?  Or is that yet to come?

--bb
Feb 19 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 The font is pretty darned small over here too.  Also WinXP/FF2.  I 
 wouldn't say unreadable, but the 1.0 changelog is definitely easier on 
 the eyes.


That's good feedback. You can try tweaking the style.css, and let me 
know what makes it look better.


 I thought a web developer was helping you to make the D site more 
 modern.  Is this the result of that?  Or is that yet to come?


That kinda fizzled out.
Feb 19 2008
next sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 The font is pretty darned small over here too.  Also WinXP/FF2.  I 
 wouldn't say unreadable, but the 1.0 changelog is definitely easier on 
 the eyes.


 
 That's good feedback. You can try tweaking the style.css, and let me 
 know what makes it look better.
 

 I thought a web developer was helping you to make the D site more 
 modern.  Is this the result of that?  Or is that yet to come?


 
 That kinda fizzled out.


Why not use the same style sheet for D 1 and 2 or do you want them to 
look different?
Feb 20 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:

 Why not use the same style sheet for D 1 and 2 or do you want them to 
 look different?


I think it's a good idea that they look a bit different.
Feb 20 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Jacob Carlborg wrote:

 Why not use the same style sheet for D 1 and 2 or do you want them to 
 look different?


 
 I think it's a good idea that they look a bit different.


I do like that there's a difference.  But I think the color scheme may 
be enough to achieve that.

--bb
Feb 20 2008
parent Jacob Carlborg <doobnet gmail.com> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 Jacob Carlborg wrote:

 Why not use the same style sheet for D 1 and 2 or do you want them to 
 look different?


 I think it's a good idea that they look a bit different.


 
 I do like that there's a difference.  But I think the color scheme may 
 be enough to achieve that.
 
 --bb


Why not just add "font-family: Helvetica, Verdana, Arial, sans-serif;" 
in D 2's style sheet in "body" like D 1 has
Feb 20 2008
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
I sent you an email, did you receive it?  Or did I use the wrong address?

-[Unknown]


Walter Bright wrote:

 Bill Baxter wrote:

 The font is pretty darned small over here too.  Also WinXP/FF2.  I 
 wouldn't say unreadable, but the 1.0 changelog is definitely easier on 
 the eyes.


 
 That's good feedback. You can try tweaking the style.css, and let me 
 know what makes it look better.
 

 I thought a web developer was helping you to make the D site more 
 modern.  Is this the result of that?  Or is that yet to come?


 
 That kinda fizzled out.
Feb 22 2008
prev sibling parent Jacob Carlborg <doobnet gmail.com> writes:
Bill Baxter wrote:

 torhu wrote:

 Walter Bright wrote:

 A whole lotta library improvements.


 I had to copy and paste the 2.0 changelog into my editor to be able to 
 even read it.  Would it be possible to get a readable font face and 
 size? There is no shame in just using black text on a white background 
 either. Please?

 I use FF 2 on winxp, so I don't think I have a weird setup.  19 inch 
 CRT, 1152x864. That's pretty mainstream, and the 1.0 docs look just 
 fine on my screen.


 
 The font is pretty darned small over here too.  Also WinXP/FF2.  I 
 wouldn't say unreadable, but the 1.0 changelog is definitely easier on 
 the eyes.
 
 I thought a web developer was helping you to make the D site more 
 modern.  Is this the result of that?  Or is that yet to come?
 
 --bb


It's the same in osx/ff3beta and osx/safari
Feb 20 2008
prev sibling parent Jascha Wetzel <firstname mainia.de> writes:
torhu wrote:

 Walter Bright wrote:

 A whole lotta library improvements.


 
 I had to copy and paste the 2.0 changelog into my editor to be able to 
 even read it.  Would it be possible to get a readable font face and 
 size? There is no shame in just using black text on a white background 
 either. Please?
 
 I use FF 2 on winxp, so I don't think I have a weird setup.  19 inch 
 CRT, 1152x864. That's pretty mainstream, and the 1.0 docs look just fine 
 on my screen.


it's readable but still *pretty* small on ff2/linux and opera/vista
Feb 20 2008
prev sibling next sibling parent Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 A whole lotta library improvements.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip
 
 I had planned on doing struct destructors for this update, but they are 
 not done yet.


Thanks!
What happened to my fixes to std.math? They are still in phobos candidate, but 
not in the trunk.
Feb 19 2008
prev sibling next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
Walter Bright wrote:


 A whole lotta library improvements.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip
 
 I had planned on doing struct destructors for this update, but they are
 not done yet.


Thanks!

If anybody cares about Konqueror, phobos 2 docs layout is broken in
Konqueror 3 and 4. I suspect this is because of the possibly redundant
</div> tag right above <div id="content">.
Feb 20 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Max Samukha wrote:

 If anybody cares about Konqueror, phobos 2 docs layout is broken in
 Konqueror 3 and 4. I suspect this is because of the possibly redundant
 </div> tag right above <div id="content">.


Try it now.
Feb 20 2008
parent Max Samukha <maxsamukha gmail.com> writes:
Walter Bright wrote:


 Max Samukha wrote:

 If anybody cares about Konqueror, phobos 2 docs layout is broken in
 Konqueror 3 and 4. I suspect this is because of the possibly redundant
 </div> tag right above <div id="content">.


 
 Try it now.


Fixed.
Feb 20 2008
prev sibling next sibling parent reply Extrawurst <spam extrawurst.org> writes:
Walter Bright schrieb:

 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they 
 are not done yet.


btw. whats the nothrow keyword gonna be for ?


~Extrawurst
Feb 20 2008
parent reply Jacob Carlborg <doobnet gmail.com> writes:
Extrawurst wrote:

 Walter Bright schrieb:

 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they 
 are not done yet.


 
 btw. whats the nothrow keyword gonna be for ?
 
 
 ~Extrawurst


Indicating that a function/method won't throw an exception?
Feb 20 2008
parent reply Extrawurst <spam extrawurst.org> writes:
Jacob Carlborg schrieb:

 Extrawurst wrote:

 Walter Bright schrieb:

 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they 
 are not done yet.


 btw. whats the nothrow keyword gonna be for ?


 ~Extrawurst


 Indicating that a function/method won't throw an exception?


yeah but what happend to the express-such-things-via-documention policy 
to keep syntax simple ?
Feb 20 2008
next sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
Extrawurst wrote:

 Jacob Carlborg schrieb:

 Extrawurst wrote:

 Walter Bright schrieb:

 A whole lotta library improvements.

 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.027.zip

 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.011.zip

 I had planned on doing struct destructors for this update, but they 
 are not done yet.


 btw. whats the nothrow keyword gonna be for ?


 ~Extrawurst


 Indicating that a function/method won't throw an exception?


 
 yeah but what happend to the express-such-things-via-documention policy 
 to keep syntax simple ?


The compiler can probably do some optimization if it knows that
Feb 20 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:

 The compiler can probably do some optimization if it knows that


Exactly. This will become more important later.
Feb 20 2008
prev sibling parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
 Indicating that a function/method won't throw an exception?


 
 yeah but what happend to the express-such-things-via-documention policy
 to keep syntax simple ?


 
 The compiler can probably do some optimization if it knows that


It is also very helpful when writing code to know that a function you are 
calling won't throw an exception - it means you have three kinds of 
functions: those that don't throw, those with comments telling you what 
they throw, and those that you need to fix the comments for.
Feb 20 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Graham St Jack wrote:

 It is also very helpful when writing code to know that a function you are 
 calling won't throw an exception - it means you have three kinds of 
 functions: those that don't throw, those with comments telling you what 
 they throw, and those that you need to fix the comments for.


Experience with this indicates that it is impractical to specify what 
exceptions a function may throw. The only practical states to specify are:

1) does not throw
2) always throws
3) might throw

What is thrown is not reliably computable. For example:

import foo;
void test()
{
     foo.bar();
}

What exceptions does test() throw? That would require knowledge of the 
import foo, which is not necessarily knowable and can change over time.
Feb 20 2008
next sibling parent Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:

 Graham St Jack wrote:
 

 It is also very helpful when writing code to know that a function you 
 are calling won't throw an exception - it means you have three kinds 
 of functions: those that don't throw, those with comments telling you 
 what they throw, and those that you need to fix the comments for.


 
 
 Experience with this indicates that it is impractical to specify what 
 exceptions a function may throw. The only practical states to specify are:
 
 1) does not throw
 2) always throws
 3) might throw
 
 What is thrown is not reliably computable. For example:
 
 import foo;
 void test()
 {
     foo.bar();
 }
 
 What exceptions does test() throw? That would require knowledge of the 
 import foo, which is not necessarily knowable and can change over time.


So both of you are right!

(Heh, couldn't resist ;-) )



What my comment above incidentally uncovers is that this is a profound 
aspect that especially Programmer Group Managers should be aware of.

The ability to see things /simultaneously/ from the perspective of the 
library programmer, the app programmer, and Real Reality, is fundamental 
to the success of the Group. If all three of these persons can see it 
from all three points of view, the better. And much better. (It's a pity 
that all we have left in Finland currently on the job market are 
ex-truck-drivers. Everybody else already are in managerial positions at 
Nokia, F-Secure, and a few other firms.)
Feb 21 2008
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote


 which is not necessarily knowable and can change over time


This holds also for the reduction to the three states Always, Never, 
Sometimes.

-manfred
Feb 21 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Manfred Nowak wrote:

 Walter Bright wrote
 

 which is not necessarily knowable and can change over time


 
 This holds also for the reduction to the three states Always, Never, 
 Sometimes.


If they are part of the type signature, then it can be enforced.
Feb 21 2008
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:


 If they are part of the type signature, then it can be enforced.


For this one would have to ensure that the prerequisites of Rice's 
Theorem [http://en.wikipedia.org/wiki/Rice's_theorem] do not hold.

How to do that?

-manfred
Feb 21 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Manfred Nowak wrote:

 Walter Bright wrote:
 

 If they are part of the type signature, then it can be enforced.


 
 For this one would have to ensure that the prerequisites of Rice's 
 Theorem [http://en.wikipedia.org/wiki/Rice's_theorem] do not hold.
 
 How to do that?


Don't have to compute it, just check it since it's part of the type 
signature.
Feb 22 2008
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:


 Don't have to compute it, just check it since it's part of the type 
 signature.


Enforcing, checking but not computing? I don't get that. So I'll have 
to wait for the docs for "nothrow".

-manfred
Feb 22 2008
next sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= writes:
Manfred Nowak schrieb:

 Walter Bright wrote:
 

 Don't have to compute it, just check it since it's part of the type 
 signature.


 
 Enforcing, checking but not computing? I don't get that. So I'll have 
 to wait for the docs for "nothrow".
 
 -manfred
 


If you specify that some function does not throw an exception, you can enforce
that simply by disallowing the use of "throw", as well as the use of any
function which does not specify "nothrow" inside of the function. I'd guess
thats how it's supposed to work.

With this system, there would of course be some functions, which could never
throw an exception, but are not allowed to carry the nothrow flag, however
(i.e. a function which catches all the exceptions of all used functions).
Feb 22 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Sönke Ludwig wrote:

 Manfred Nowak schrieb:

 Walter Bright wrote:


 Don't have to compute it, just check it since it's part of the type 
 signature.


 Enforcing, checking but not computing? I don't get that. So I'll have 
 to wait for the docs for "nothrow".

 -manfred


 
 If you specify that some function does not throw an exception, you can 
 enforce
 that simply by disallowing the use of "throw", as well as the use of any
 function which does not specify "nothrow" inside of the function. I'd guess
 thats how it's supposed to work.
 
 With this system, there would of course be some functions, which could 
 never
 throw an exception, but are not allowed to carry the nothrow flag, however
 (i.e. a function which catches all the exceptions of all used functions).


According to the conference slides, it'll allow any function that just 
has a "catch exception". It does indeed support catches (i.e. the 
function itself can set up exception handlers, but callers needn't).

Also be aware that "new" throws exceptions if there's no memory left.
Feb 22 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Manfred Nowak wrote:

 Walter Bright wrote:
 

 Don't have to compute it, just check it since it's part of the type 
 signature.


 
 Enforcing, checking but not computing?


Yes.


 I don't get that. So I'll have 
 to wait for the docs for "nothrow".


It would work just like "nothrow" does for C++.
Feb 22 2008
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:


 It would work just like "nothrow" does for C++.


BTW, wasn't there one of your arguments to have no negation in 
keywords? Which would make "exfree" a better choice?

-manfred
Feb 24 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Manfred Nowak wrote:

 Walter Bright wrote:
 

 It would work just like "nothrow" does for C++.


 
 BTW, wasn't there one of your arguments to have no negation in 
 keywords?


Yes. But everyone knows what "nothrow" means.


 Which would make "exfree" a better choice?
Feb 24 2008
parent Derek Parnell <derek psych.ward> writes:
On Sun, 24 Feb 2008 11:53:00 -0800, Walter Bright wrote:


 Manfred Nowak wrote:

 Walter Bright wrote:
 

 It would work just like "nothrow" does for C++.


 
 BTW, wasn't there one of your arguments to have no negation in 
 keywords?


 
 Yes. But everyone knows what "nothrow" means.


ROTFLMAO

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Feb 24 2008
prev sibling parent reply Graham St Jack <graham.stjack internode.on.net> writes:
 It would work just like "nothrow" does for C++.


Just checking - I hope this means that if a nothrow function actually DID 
try to throw an exception (by calling something that throws), compiler-
generated code would trap it and terminate the program with an error 
message?
Feb 24 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Graham St Jack wrote:

 It would work just like "nothrow" does for C++.


 
 Just checking - I hope this means that if a nothrow function actually DID 
 try to throw an exception (by calling something that throws), compiler-
 generated code would trap it and terminate the program with an error 
 message?


No, but it will try to detect errors at compile time.
Feb 24 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright escribió:

 Graham St Jack wrote:

 It would work just like "nothrow" does for C++.


 Just checking - I hope this means that if a nothrow function actually 
 DID try to throw an exception (by calling something that throws), 
 compiler-
 generated code would trap it and terminate the program with an error 
 message?


 
 No, but it will try to detect errors at compile time.


Does this mean this will not compile:

int foo(int[] someArray, int someIndex) nothrow {
	return someArray[someIndex];
}

but this will:

int foo(int[] someArray, int someIndex) nothrow {
	if (someIndex < someArray.length) {
		return someArray[someIndex];
	} else {
		return -1;
	}
}
Feb 25 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:

 Does this mean this will not compile:
 
 int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }
 
 but this will:
 
 int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }


I don't know yet. But the idea is to do static checking of what can throw.
Feb 25 2008
next sibling parent reply Graham St Jack <graham.stjack internode.on.net> writes:
On Mon, 25 Feb 2008 01:44:15 -0800, Walter Bright wrote:


 Ary Borenszweig wrote:

 Does this mean this will not compile:
 
 int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }
 
 but this will:
 
 int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }


 
 I don't know yet. But the idea is to do static checking of what can
 throw.


It will be a good trick if you can pull it off. I don't see how it can be 
done without examining the source code of all the called functions, 
leaving us back where we started with throw specs.

The C++ approach of a runtime check isn't perfect, but at least it can be 
done, and provides a more definite form of documentation than comments.

If the static checks aren't done well enough and runtime checks aren't 
done at all, I would prefer to rely on comments.
Feb 25 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Graham St Jack wrote:

 It will be a good trick if you can pull it off. I don't see how it can be 
 done without examining the source code of all the called functions, 
 leaving us back where we started with throw specs.
 
 The C++ approach of a runtime check isn't perfect, but at least it can be 
 done, and provides a more definite form of documentation than comments.


Are you sure it does a runtime check for nothrow?


 If the static checks aren't done well enough and runtime checks aren't 
 done at all, I would prefer to rely on comments.
Feb 25 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Graham St Jack wrote:

 It will be a good trick if you can pull it off. I don't see how it can be
 done without examining the source code of all the called functions,
 leaving us back where we started with throw specs.

 The C++ approach of a runtime check isn't perfect, but at least it can be
 done, and provides a more definite form of documentation than comments.


 Are you sure it does a runtime check for nothrow?


I think it depends on the compiler.  The MS compiler, for example, ignores
exception specs, except
possibly for nothrow (it's been a while and I cant recall).  However, isn't the
app supposed to terminate if an
exception is thrown from a nothrow routine?  I don't have my copy of the spec
handy or I'd check.


Sean
Feb 26 2008
prev sibling next sibling parent reply Graham St Jack <Graham.StJack internode.on.net> writes:
On Mon, 25 Feb 2008 08:55:17 -0800, Walter Bright wrote:


 Graham St Jack wrote:

 It will be a good trick if you can pull it off. I don't see how it can
 be done without examining the source code of all the called functions,
 leaving us back where we started with throw specs.
 
 The C++ approach of a runtime check isn't perfect, but at least it can
 be done, and provides a more definite form of documentation than
 comments.


 
 Are you sure it does a runtime check for nothrow?


g++ certainly does runtime checking. I'm sure it does no static checking 
at all.

We use the throw() and throw(list-of-exceptions) specs all the time in 
our C++ code, relying on the runtime checking to tell us if we get it 
wrong. This is quite horrible compared to static checking, but it is a 
lot better than nothing, because we find out what exception was thrown 
and which throw-spec was violated.

The vast majority of functions in our C++ code use an empty throw-spec, 
so if D had nothrow with some static checking plus a runtime check, I 
would be better off than I am now with C++. Of course I would be even 
better off if the static checking was complete, but that seems to be too 
tricky.



 

 If the static checks aren't done well enough and runtime checks aren't
 done at all, I would prefer to rely on comments.
Feb 26 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Graham St Jack (Graham.StJack internode.on.net)'s article

 On Mon, 25 Feb 2008 08:55:17 -0800, Walter Bright wrote:

 Graham St Jack wrote:

 It will be a good trick if you can pull it off. I don't see how it can
 be done without examining the source code of all the called functions,
 leaving us back where we started with throw specs.

 The C++ approach of a runtime check isn't perfect, but at least it can
 be done, and provides a more definite form of documentation than
 comments.


 Are you sure it does a runtime check for nothrow?


 g++ certainly does runtime checking. I'm sure it does no static checking
 at all.
 We use the throw() and throw(list-of-exceptions) specs all the time in
 our C++ code, relying on the runtime checking to tell us if we get it
 wrong. This is quite horrible compared to static checking, but it is a
 lot better than nothing, because we find out what exception was thrown
 and which throw-spec was violated.
 The vast majority of functions in our C++ code use an empty throw-spec,
 so if D had nothrow with some static checking plus a runtime check, I
 would be better off than I am now with C++. Of course I would be even
 better off if the static checking was complete, but that seems to be too
 tricky.


The nice thing about offering nothrow only is that it implicitly marks any
unlabeled routine as one that
may throw an exception.  The problem in C++ with explicit exception specs is
those unlabeled
routines--they can throw anything but they're also callable from nothrow
routines because they might
not actually throw anything.  It's a mess.


Sean
Feb 26 2008
parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Wed, 27 Feb 2008 00:47:00 +0000, Sean Kelly wrote:


 == Quote from Graham St Jack (Graham.StJack internode.on.net)'s article

 On Mon, 25 Feb 2008 08:55:17 -0800, Walter Bright wrote:

 Graham St Jack wrote:

 It will be a good trick if you can pull it off. I don't see how it
 can be done without examining the source code of all the called
 functions, leaving us back where we started with throw specs.

 The C++ approach of a runtime check isn't perfect, but at least it
 can be done, and provides a more definite form of documentation than
 comments.


 Are you sure it does a runtime check for nothrow?


 g++ certainly does runtime checking. I'm sure it does no static
 checking at all.
 We use the throw() and throw(list-of-exceptions) specs all the time in
 our C++ code, relying on the runtime checking to tell us if we get it
 wrong. This is quite horrible compared to static checking, but it is a
 lot better than nothing, because we find out what exception was thrown
 and which throw-spec was violated.
 The vast majority of functions in our C++ code use an empty throw-spec,
 so if D had nothrow with some static checking plus a runtime check, I
 would be better off than I am now with C++. Of course I would be even
 better off if the static checking was complete, but that seems to be
 too tricky.


 
 The nice thing about offering nothrow only is that it implicitly marks
 any unlabeled routine as one that may throw an exception.  The problem
 in C++ with explicit exception specs is those unlabeled routines--they
 can throw anything but they're also callable from nothrow routines
 because they might not actually throw anything.  It's a mess.
 
 
 Sean


Agreed.
Feb 26 2008
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:

 Graham St Jack wrote:
 

 It will be a good trick if you can pull it off. I don't see how it can 
 be done without examining the source code of all the called functions, 
 leaving us back where we started with throw specs.

 The C++ approach of a runtime check isn't perfect, but at least it can 
 be done, and provides a more definite form of documentation than 
 comments.


 
 
 Are you sure it does a runtime check for nothrow?
 

 If the static checks aren't done well enough and runtime checks aren't 
 done at all, I would prefer to rely on comments.




IMHO, it would behoove the compiler to keep track of possible/potential 
exceptions a function can throw. (Just as well as (again, IMHO) it would 
behoove the compiler to keep track of functions that /potentially/ have 
side effects.)

The workload for doing either defines a pattern, and doing the other is 
simply a repetition of the pattern. Therefore, doing both is not much 
more work than doing only one of these.

In the optimal future, entering a function would give you information 
(not necessarily runtime, but definitely info when browsing the docs) on 
whether it potentially generates an exception/changes data. A year after 
this info is standard in the docs, several new ideas about Functional 
Programming will emerge, in D. (Ermmmm, new to D, anyway.)

-----

Keeping track of these two things may be considered superfluous 
drudgery, but the potential benefits well outweigh the invested effort.
Mar 03 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Georg Wrede wrote:

 Walter Bright wrote:

 Graham St Jack wrote:


 It will be a good trick if you can pull it off. I don't see how it 
 can be done without examining the source code of all the called 
 functions, leaving us back where we started with throw specs.

 The C++ approach of a runtime check isn't perfect, but at least it 
 can be done, and provides a more definite form of documentation than 
 comments.



 Are you sure it does a runtime check for nothrow?


 If the static checks aren't done well enough and runtime checks 
 aren't done at all, I would prefer to rely on comments.




 
 IMHO, it would behoove the compiler to keep track of possible/potential 
 exceptions a function can throw. (Just as well as (again, IMHO) it would 
 behoove the compiler to keep track of functions that /potentially/ have 
 side effects.)


There's a few problems with what you're asking for:
- extern(D)
- .di files
- delegates
- dynamic loading

There's also the matter of executable bloat.
Mar 03 2008
parent Georg Wrede <georg nospam.org> writes:
    Caveat lector!
    Er, upon proofreading it dawned upon me:

        This post does NOT interest Walter or anybody
        else who is concerned with compiler issues,
        the laguage itself, or optimizing. (What, is that
        like everybody in this newsgroup??)

        BUT, it still is very relevant to the advancement
        of D.

        IDE developers, framework architects, and library
        programmers may want to read this.


Christopher Wright wrote:

 Georg Wrede wrote:

 IMHO, it would behoove the compiler to keep track of 
 possible/potential exceptions a function can throw. (Just as well as 
 (again, IMHO) it would behoove the compiler to keep track of functions 
 that /potentially/ have side effects.)


 
 There's a few problems with what you're asking for:
 - extern(D)
 - .di files
 - delegates
 - dynamic loading


We probably should reverse the bookkeeping to what the function does 
/not/ throw. With that, the above things would all be classified as 
unknown, which translates to "no exception is guaranteed to not get 
thrown". (For recursive implications, see below.)


 There's also the matter of executable bloat.


All of this is compile-time-only stuff. Once compiled, the code should 
"look like" code that's never heard of the issue. But it still does the 
Right Thing.



To be more precise, we're not [here] interested in what a function 
throws, only in what it is guaranteed /not/ to throw. For example, an 
in-place string transformation would be guaranteed to not throw an 
out-of-memory exception. (Unless the programmer is an idiot, but that 
doesn't count here.)

By the same token, anytime I write a function in my code, the result of 
what other functions it calls and which they call in their turn, can be 
drawn as a tree structure. If we had machine readable documentation on 
each of the leaves, telling us /what it will not throw/, we might go on 
to the function that uses the leaf, see if it creates new kinds of 
exceptions and whether it may throw the new ones or any existing 
exceptions, and then compute the Set Intersection of the exceptions any 
of them /can not throw/. This gives us a guaranteed set of exceptions 
that /will not be thrown/ as a result of calling this (er...) 
Intermediate Node in the tree. By recursively applying this reasoning we 
ultimately end up with a hard document about my Brand New function, and 
what it doesn't throw.

(( And as you pointed out earlier, anytime any of the leaves or the 
nodes uses any of: extern(D), .di files, delegates, dynamic loading; the 
entire tree gets tainted. That might actually be a shortcut from 
traversing the tree since we don't need any more information: NO 
EXCEPTION is guaranteed not to be thrown. ))

While we're at it, this precisely same kind of analysis could be made 
about side effects. And even using precisely the same mechanics.

All we need is data on the primary functions. Everything else is 
automatically computable from that. Including the library functions. (As 
in Phobos, etc.)


The end result is, by the time we've written our own function, it is 
KNOWABLE what exceptions OUR function doesn't throw. And it is knowable 
whether our function DOES NOT create ANY side effects.

The value of these two hardly need advertising. Functional programming, 
real-time stuff, robust code, secure code, the list goes on and on.
Mar 07 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Graham St Jack wrote:

 It will be a good trick if you can pull it off. I don't see how it can be 
 done without examining the source code of all the called functions, 
 leaving us back where we started with throw specs.


I think the idea would be that nothrow is part of the function signature 
and a nothrow function can only call other nothrow functions or wrap any 
function calls or news in a catch(Exception) (since there's no way to 
know specifically which exceptions could be thrown).
Feb 26 2008
next sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Tue, 26 Feb 2008 23:36:34 -0800, Robert Fraser wrote:


 Graham St Jack wrote:

 It will be a good trick if you can pull it off. I don't see how it can
 be done without examining the source code of all the called functions,
 leaving us back where we started with throw specs.


 
 I think the idea would be that nothrow is part of the function signature
 and a nothrow function can only call other nothrow functions or wrap any
 function calls or news in a catch(Exception) (since there's no way to
 know specifically which exceptions could be thrown).


That would work, but my feeling is that it would be so restrictive that 
hardly any functions could be nothrow.
Feb 27 2008
prev sibling parent Georg Wrede <georg nospam.org> writes:
Robert Fraser wrote:

 Graham St Jack wrote:
 

 It will be a good trick if you can pull it off. I don't see how it can 
 be done without examining the source code of all the called functions, 
 leaving us back where we started with throw specs.


 
 
 I think the idea would be that nothrow is part of the function signature 
 and a nothrow function can only call other nothrow functions or wrap any 
 function calls or news in a catch(Exception) (since there's no way to 
 know specifically which exceptions could be thrown).


Yes. Therefore, the compiler has to know which functions are "nothrow", 
at compile time.

Keeping track of this would be a lot of work -- ONE single time when 
implementing the bokkeeping of it. Later, the compiler programmer 
(Walter?) would only have to deal with this when creating totally new 
basic functions or severely altering the existing ones.

And at that time it would not feel like a lot of work. Probably it would 
be like filling in a few items on a row in a (sql-like) table of 
function properties for the compiler.
Mar 03 2008
prev sibling next sibling parent reply eao197 <eao197 intervale.ru> writes:
On Mon, 25 Feb 2008 12:44:15 +0300, Walter Bright  =

<newshound1 digitalmars.com> wrote:


 Ary Borenszweig wrote:

 Does this mean this will not compile:
  int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }
  but this will:
  int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }


 I don't know yet. But the idea is to do static checking of what can  =



 throw.


Just my $0.02 about nothrow and DesignByContract: I think that nothrow a=
re  =

incompatible with DbC. A function/method could have contracts or nothrow=
  =

but not both of them. It is especially actual for virtual (non-final)  =

methods. Suppose that some class has:

class A {
   public void cleanup() nothrow { ... };
}

so it could be safely used in 'finally' statement:

A someResource =3D acquireResource();
try { ... /* some processing */ ... }
finally {
   someResource.cleanup; /* looks like exception-safe action */
}

But if there is a derived class B, which overrides cleanup() with  =

postcondition:

class B : A {
   public void cleanup() nothrow
     out { ... some checking ... }
     body { ... some actions ... }
}

and acquireResource() would return B instead of A, then the code above  =

won't be exception-safe. Moreover the behaviour of 'someResource.cleanup=
'  =

would depend on compiler switches.

-- =

Regards,
Yauheni Akhotnikau
Feb 25 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
eao197 wrote:

 On Mon, 25 Feb 2008 12:44:15 +0300, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 

 Ary Borenszweig wrote:

 Does this mean this will not compile:
  int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }
  but this will:
  int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }


 I don't know yet. But the idea is to do static checking of what can 
 throw.


 
 Just my $0.02 about nothrow and DesignByContract: I think that nothrow 
 are incompatible with DbC. A function/method could have contracts or 
 nothrow but not both of them. It is especially actual for virtual 
 (non-final) methods. Suppose that some class has:
 
 class A {
   public void cleanup() nothrow { ... };
 }
 
 so it could be safely used in 'finally' statement:
 
 A someResource = acquireResource();
 try { ... /* some processing */ ... }
 finally {
   someResource.cleanup; /* looks like exception-safe action */
 }
 
 But if there is a derived class B, which overrides cleanup() with 
 postcondition:
 
 class B : A {
   public void cleanup() nothrow
     out { ... some checking ... }
     body { ... some actions ... }
 }
 
 and acquireResource() would return B instead of A, then the code above 
 won't be exception-safe. Moreover the behaviour of 
 'someResource.cleanup' would depend on compiler switches.
 


So the code generated depends on compiler switches... Isn't this always 
true? The "nothrow" spec could only actually be used when building 
release mode, and in non-release mode code, exception handling frames 
are always set up. This means that nothrow functions can still use 
assert() and array indexing without worries, since these only throw 
exceptions in non-release-mode code.

Of course, then problems occur when mixing code compiled with different 
switches...
Feb 26 2008
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 27 Feb 2008 10:42:07 +0300, Robert Fraser  =

<fraserofthenight gmail.com> wrote:


 eao197 wrote:

 On Mon, 25 Feb 2008 12:44:15 +0300, Walter Bright  =





 <newshound1 digitalmars.com> wrote:


 Ary Borenszweig wrote:

 Does this mean this will not compile:
  int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }
  but this will:
  int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }


 I don't know yet. But the idea is to do static checking of what can =






 =


 throw.


  Just my $0.02 about nothrow and DesignByContract: I think that nothr=




ow  =


 are incompatible with DbC. A function/method could have contracts or =




 =


 nothrow but not both of them. It is especially actual for virtual  =





 (non-final) methods. Suppose that some class has:
  class A {
   public void cleanup() nothrow { ... };
 }
  so it could be safely used in 'finally' statement:
  A someResource =3D acquireResource();
 try { ... /* some processing */ ... }
 finally {
   someResource.cleanup; /* looks like exception-safe action */
 }
  But if there is a derived class B, which overrides cleanup() with  =





 postcondition:
  class B : A {
   public void cleanup() nothrow
     out { ... some checking ... }
     body { ... some actions ... }
 }
  and acquireResource() would return B instead of A, then the code abo=




ve  =


 won't be exception-safe. Moreover the behaviour of  =





 'someResource.cleanup' would depend on compiler switches.


 So the code generated depends on compiler switches... Isn't this alway=


s  =


 true? The "nothrow" spec could only actually be used when building  =



 release mode, and in non-release mode code, exception handling frames =


 =


 are always set up. This means that nothrow functions can still use  =



 assert() and array indexing without worries, since these only throw  =



 exceptions in non-release-mode code.

 Of course, then problems occur when mixing code compiled with differen=


t  =


 switches...


I'm affraid that you misunderstand my point. When you use a[i] or new in=
  =

nothrow function you always known what could happen. But if you call  =

virtual method from any object you can't predict its behaviour. Because =
 =

the method implementation in some derived class could define contract fo=
r  =

that method. And you may don't known about it.

And becouse of this I think that 'nothrow' is a kind of function contrac=
t.  =

And if a function defines such contract then it can't redefine it in  =

derived classes.

-- =

Regards,
Yauheni Akhotnikau
Feb 27 2008
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
eao197 escribió:

 eao197 wrote:


 I'm affraid that you misunderstand my point. When you use a[i] or new in 
 nothrow function you always known what could happen. But if you call 
 virtual method from any object you can't predict its behaviour. Because 
 the method implementation in some derived class could define contract 
 for that method. And you may don't known about it.
 
 And becouse of this I think that 'nothrow' is a kind of function 
 contract. And if a function defines such contract then it can't redefine 
 it in derived classes.


But contracts are predictable. Say B extends A, and A has a foo method. 
If foo says nothrow, than if B overrides foo, it must also be nothrow 
(this will be enforced by the compiler, I'm sure).

For in and out, http://www.digitalmars.com/d/1.0/dbc.html shows there 
will be no problem.
Feb 27 2008
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 27 Feb 2008 12:40:03 +0300, Ary Borenszweig <ary esperanto.org.ar>  
wrote:


 eao197 escribió:

 eao197 wrote:


 I'm affraid that you misunderstand my point. When you use a[i] or new  
 in nothrow function you always known what could happen. But if you call  
 virtual method from any object you can't predict its behaviour. Because  
 the method implementation in some derived class could define contract  
 for that method. And you may don't known about it.
  And becouse of this I think that 'nothrow' is a kind of function  
 contract. And if a function defines such contract then it can't  
 redefine it in derived classes.


 But contracts are predictable. Say B extends A, and A has a foo method.  
 If foo says nothrow, than if B overrides foo, it must also be nothrow  
 (this will be enforced by the compiler, I'm sure).


B.foo may looks like:

void foo() nothrow
   in { assert( <some condition> ); }
   out { assert( <some condition> ); }
   body { <some code without exception> }

Body of B.foo() doesn't throw exception but assert in pre/postcondition  
could do that. A call of B.foo could produce exception but B.foo is  
declared as 'nothrow' :(

-- 
Regards,
Yauheni Akhotnikau
Feb 27 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
eao197 wrote:

 B.foo may looks like:
 
 void foo() nothrow
   in { assert( <some condition> ); }
   out { assert( <some condition> ); }
   body { <some code without exception> }
 
 Body of B.foo() doesn't throw exception but assert in pre/postcondition 
 could do that. A call of B.foo could produce exception but B.foo is 
 declared as 'nothrow' :(
 


I'm happy with that. Contracts aren't compiled in release mode, and they 
aren't part of the function; they're part of the tests. I'd hate to have 
to avoid one language feature for reliability in order to gain another one.
Feb 27 2008
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 27 Feb 2008 16:56:34 +0300, Christopher Wright  
<dhasenan gmail.com> wrote:


 eao197 wrote:

 B.foo may looks like:
  void foo() nothrow
   in { assert( <some condition> ); }
   out { assert( <some condition> ); }
   body { <some code without exception> }
  Body of B.foo() doesn't throw exception but assert in  
 pre/postcondition could do that. A call of B.foo could produce  
 exception but B.foo is declared as 'nothrow' :(


 I'm happy with that. Contracts aren't compiled in release mode, and they  
 aren't part of the function; they're part of the tests. I'd hate to have  
 to avoid one language feature for reliability in order to gain another  
 one.


People are different. You want to compile your programs in release mode to  
remove any run-time checks and contracts. I want to save them in my  
programs to catch errors at the most earliest stage ('fail fast' principle  
is very important in server-side systems). But a programing language must  
provide logical and consistent rules for each of us.

-- 
Regards,
Yauheni Akhotnikau
Feb 27 2008
parent reply Russell Lewis <webmaster villagersonline.com> writes:
I wonder if asserts() should be the exception to nothrow.  Like eao197, 
I normally run my programs with assert()s turned on.  But it would be a 
shame to lose nothrow because of that.

Are assert()s catchable?  Other than in some sort of weird systems 
programming context (where you are running one program inside another), 
why would you want to catch them?  (I'm sure somebody has a compelling 
example...but would that example be ruined by 
asserts-that-penetrate-nothrow.)

eao197 wrote:

 On Wed, 27 Feb 2008 16:56:34 +0300, Christopher Wright 
 <dhasenan gmail.com> wrote:
 

 eao197 wrote:

 B.foo may looks like:
  void foo() nothrow
   in { assert( <some condition> ); }
   out { assert( <some condition> ); }
   body { <some code without exception> }
  Body of B.foo() doesn't throw exception but assert in 
 pre/postcondition could do that. A call of B.foo could produce 
 exception but B.foo is declared as 'nothrow' :(


 I'm happy with that. Contracts aren't compiled in release mode, and 
 they aren't part of the function; they're part of the tests. I'd hate 
 to have to avoid one language feature for reliability in order to gain 
 another one.


 
 People are different. You want to compile your programs in release mode 
 to remove any run-time checks and contracts. I want to save them in my 
 programs to catch errors at the most earliest stage ('fail fast' 
 principle is very important in server-side systems). But a programing 
 language must provide logical and consistent rules for each of us.
 
 --Regards,
 Yauheni Akhotnikau
Feb 27 2008
parent reply eao197 <eao197 intervale.ru> writes:
On Thu, 28 Feb 2008 07:27:24 +0300, Russell Lewis  =

<webmaster villagersonline.com> wrote:


 I wonder if asserts() should be the exception to nothrow.  Like eao197=


,  =


 I normally run my programs with assert()s turned on.  But it would be =


a  =


 shame to lose nothrow because of that.

 Are assert()s catchable?


Yes, it is catchable:

import std.stdio;
import std.asserterror;

void do_something( int i, int j )
   in
     {
       assert( i < j, "i must be lesser than j" );
     }
   body
     {
       writefln( "i=3D", i, ", j=3D", j );
     }

void main()
   {
     try
       {
         do_something( 0, 1 );
         do_something( 1, 0 );
       }
     catch( AssertError x )
       {
         writefln( x );
       }
   }


 Other than in some sort of weird systems programming context (where yo=


u  =


 are running one program inside another), why would you want to catch  =



 them?


It is not necessary to catch AssertError. Sometimes it is necessary to  =

catch any error. For example, in a HTTP-server you could start processin=
g  =

of a new request and catch different kinds of errors to make appropriate=
  =

response:

void processNewRequest( SomeRequestData request )
   {
     try
       {
         requestProcessingActions( request );
       }
     catch( Error x )
       {
         logError( x );
         classifyErrorAndMakeAppropriateResponse( x );
       }
   }

There is no difference between some application-logic error, index out o=
f  =

range error, no memory error or AssertError. The request processing fail=
ed  =

and the reason must be logged.


  (I'm sure somebody has a compelling example...but would that example =


be  =


 ruined by asserts-that-penetrate-nothrow.)


May be I don't understand your question, but I think that nothrow should=
  =

help write exception-safe code. For example, some resource cleanup actio=
ns  =

in finally statements:

auto firstStream =3D createStream();
auto secondStream =3D createStream();
auto thirdStream =3D createStream();

try {
   firstStream.open( 'first' );
   secondStream.open( 'second' );
   thirdStream.open( 'third' );
   ... some actions with firstStream, secondStream and thirdStream ...
}
finally {
   // All stream should be closed here.
   firstStream.close;
   secondStream.close;
   thirdStream.close;
   ... some other cleanup code...
}

It is rather naive resource cleanup code, because without nothrow  =

specification we can't assume that a 'close' call doesn't throw an  =

exception. If close can throw exceptions we must rewrite it, for example=
:

finally {
   void safeClose( Stream s ) { try { s.close; } catch( Error ) {} }
   safeClose( firstStream );
   safeClose( secondStream );
   safeClose( thirdStream );
   ... some other cleanup code...
}

But if we know that close doesn't throw exceptions then we can write les=
s  =

code (without safeClose helper function). And I suppose that 'nothrow' i=
s  =

a promise of function's developer that the function doesn't throw an  =

exception.

But if 'close' is written as:

close() nothrow
   in { assert( is_opened(), "close() must be called only in stream is  =

open" ); }
   body { ... }

I think that such implementation brokes a promise about non-throwing  =

exception. For example, what if some exception is thrown at  =

secondStream.open("second") in the sample above? We are going to finally=
  =

statement, successfully close firstStream, but get AssertError at  =

secondStream.close(). It breaks finally statement and we have no chance =
to  =

perform other cleanup code.

So I think that nothrow is a contract which is violated by any assert in=
  =

in/out statements. And because of that nothrow shouldn't be used with  =

in/out contracts.

But here is another kind of problem with nothrow. I don't know is it  =

possible to write really exception free code in D (AFAIK it is impossibl=
e  =

on JVM/.NET because VM could raise some of it internal exception at any =
 =

moment). Exceptions could be everywere -- on accessing array items, on  =

string concatenations, on new statements, on calling some functions with=
  =

pre/postconditions and so on. So probably nothrow function could throw  =

some kind of exceptions even if function's writter don't known about the=
m  =

(it reminds me unchecked exceptions in Java which could be thrown despit=
e  =

of method's exception specification). In such case AssertError could be =
 =

one of such 'unchecked exception' in D, and in such case nothrow could b=
e  =

combined with in/out statements. But in such case the profit from nothro=
w  =

is under doubt for me.

Disclaimer: I know that my sample with streams and resource cleanup in  =

finally statement could be rewritten in different ways. It is just a  =

sample.


 eao197 wrote:

 On Wed, 27 Feb 2008 16:56:34 +0300, Christopher Wright  =





 <dhasenan gmail.com> wrote:


 eao197 wrote:

 B.foo may looks like:
  void foo() nothrow
   in { assert( <some condition> ); }
   out { assert( <some condition> ); }
   body { <some code without exception> }
  Body of B.foo() doesn't throw exception but assert in  =









 pre/postcondition could do that. A call of B.foo could produce  =









 exception but B.foo is declared as 'nothrow' :(


 I'm happy with that. Contracts aren't compiled in release mode, and =






 =


 they aren't part of the function; they're part of the tests. I'd hat=






e  =


 to have to avoid one language feature for reliability in order to ga=






in  =


 another one.


  People are different. You want to compile your programs in release  =





 mode to remove any run-time checks and contracts. I want to save them=




  =


 in my programs to catch errors at the most earliest stage ('fail fast=




'  =


 principle is very important in server-side systems). But a programing=




  =


 language must provide logical and consistent rules for each of us.
  --Regards,
 Yauheni Akhotnikau






-- =

Regards,
Yauheni Akhotnikau
Feb 28 2008
parent reply Russell Lewis <webmaster villagersonline.com> writes:
eao197 wrote:

 On Thu, 28 Feb 2008 07:27:24 +0300, Russell Lewis 
 <webmaster villagersonline.com> wrote:
 

 I wonder if asserts() should be the exception to nothrow.  Like 
 eao197, I normally run my programs with assert()s turned on.  But it 
 would be a shame to lose nothrow because of that.

 Are assert()s catchable?


 
 Yes, it is catchable:


(snip)


 Other than in some sort of weird systems programming context (where 
 you are running one program inside another), why would you want to 
 catch them?


 
 It is not necessary to catch AssertError. Sometimes it is necessary to 
 catch any error. For example, in a HTTP-server you could start 
 processing of a new request and catch different kinds of errors to make 
 appropriate response:


I agree that a web server needs to post an appropriate response.  But if 
an assert() has failed, you don't know if the failure is in your main 
program, in a library, or maybe even in your network code.  In that 
case, you can't really rely on your program to keep working correctly, 
and the only sane solution would be to restart it.

My argument, then, is that you need a metaprogram or "watchdog" (such as 
the init process in *NIX, or maybe just a "web server launcher") which 
manages the server programs and restarts them when they crash.


 There is no difference between some application-logic error, index out 
 of range error, no memory error or AssertError. The request processing 
 failed and the reason must be logged.


 From the web client's or the system administrator's perspective, I 
agree.  The error should be reported to the client, and logged for the 
admin.  But from the internal-consistency-of-the-program perspective, 
these are very different.  An out-of-memory error is a (possibly 
transient) memory issue.  The internal logic of the program is intact. 
Array index out of range might (or might not) be survivable.  But a 
failed assert() means that something is (or might be) deeply wrong with 
the internal logic of the program.  That's not something, IMHO, that you 
ought to try to catch and then forget.

Things which are recoverable should throw Exceptions.  Things which are 
fatal should fail assert()s.
Feb 28 2008
parent reply eao197 <eao197 intervale.ru> writes:
On Thu, 28 Feb 2008 19:34:45 +0300, Russell Lewis  =

<webmaster villagersonline.com> wrote:


  It is not necessary to catch AssertError. Sometimes it is necessary =




to  =


 catch any error. For example, in a HTTP-server you could start  =





 processing of a new request and catch different kinds of errors to ma=




ke  =


 appropriate response:


 I agree that a web server needs to post an appropriate response.  But =


if  =


 an assert() has failed, you don't know if the failure is in your main =


 =


 program, in a library, or maybe even in your network code.  In that  =



 case, you can't really rely on your program to keep working correctly,=


  =


 and the only sane solution would be to restart it.


Violation of contract is not a sign of unrecoverable failure of the  =

program, expecially for preconditions. Quite the contrary contracts help=
  =

detect unappropriate conditions at earlier stages.

For example, SMS body in 140 bytes long. 7-bit message could be up to 16=
0  =

symbols, packed into 140 bytes SMS body. You could have 7-bit message  =

packing functions with precondition:

byte[] pack7bitMessage( byte[] message )
   in { assert( message.length <=3D 160 ); }
   body { ... }

When pack7bitMessage receives message which is longer than 160 symbols  =

there isn't any sign of unrecoverable error. For example, the too long  =

body of message may be received from SMPP PDU submit_sm from a ESME who =
 =

simply had made an error in their PDU. It may be a sign of presence of  =

error in your code for submit_sm parsing (length of SMS body not checked=
)  =

but there nothing fatal for whole application.

And that is a situation where application abort and restart don't solve =
a  =

problem -- ESME simply repeat the problem submit_sm after server restart=
  =

and server go down again and so on.


 My argument, then, is that you need a metaprogram or "watchdog" (such =


as  =


 the init process in *NIX, or maybe just a "web server launcher") which=


  =


 manages the server programs and restarts them when they crash.


A rather complex application is build from a several layers. A failure o=
n  =

some layer should abort all current processing on that layer, but parent=
  =

layer could restart the problem layer. So that model with  =

metaprogram/watchdogs or supervisor processes (from Erlang) could be  =

implemented inside a single application with use of safe languages like =
D,  =



-- =

Regards,
Yauheni Akhotnikau
Feb 29 2008
next sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
It seems that we have a significant programming style difference.  Let 
me explain and advocate for my style...

I believe that assert()s are ways to programmatically document things 
that the program must enforce.  An in() contract on a function is a 
statement that says "any code which calls me, but violates this 
contract, is buggy."  Exceptions are the way to programmatically handle 
unusual conditions in well-ordered ways.

So, in your example below, since pack7bitMessage asserts that the 
message must be no more than 160 characters, then any code which called 
it must enforce that contract.  Any code which didn't enforce the 
contract has a bug.

IMHO, if what you want is to have a function which will take input of 
any length, but refuse to encode things which are longer than 160 
characters, then it should be coded as follows:

   byte[] pack7bitMessage( byte[] message )
   {
     if(message.length > 160)
       throw InputTooLongException;

     ... encode ...
   }

This is why I argued that assert()s are unrecoverable errors and 
exceptions are reasonably recoverable.


Finally, let me ask you a question:

If an failed assert() doesn't represent an unrecoverable logic error, 
then what does???


eao197 wrote:

 On Thu, 28 Feb 2008 19:34:45 +0300, Russell Lewis 
 <webmaster villagersonline.com> wrote:
 

  It is not necessary to catch AssertError. Sometimes it is necessary 
 to catch any error. For example, in a HTTP-server you could start 
 processing of a new request and catch different kinds of errors to 
 make appropriate response:


 I agree that a web server needs to post an appropriate response.  But 
 if an assert() has failed, you don't know if the failure is in your 
 main program, in a library, or maybe even in your network code.  In 
 that case, you can't really rely on your program to keep working 
 correctly, and the only sane solution would be to restart it.


 
 Violation of contract is not a sign of unrecoverable failure of the 
 program, expecially for preconditions. Quite the contrary contracts help 
 detect unappropriate conditions at earlier stages.
 
 For example, SMS body in 140 bytes long. 7-bit message could be up to 
 160 symbols, packed into 140 bytes SMS body. You could have 7-bit 
 message packing functions with precondition:
 
 byte[] pack7bitMessage( byte[] message )
   in { assert( message.length <= 160 ); }
   body { ... }
 
 When pack7bitMessage receives message which is longer than 160 symbols 
 there isn't any sign of unrecoverable error. For example, the too long 
 body of message may be received from SMPP PDU submit_sm from a ESME who 
 simply had made an error in their PDU. It may be a sign of presence of 
 error in your code for submit_sm parsing (length of SMS body not 
 checked) but there nothing fatal for whole application.
 
 And that is a situation where application abort and restart don't solve 
 a problem -- ESME simply repeat the problem submit_sm after server 
 restart and server go down again and so on.
 

 My argument, then, is that you need a metaprogram or "watchdog" (such 
 as the init process in *NIX, or maybe just a "web server launcher") 
 which manages the server programs and restarts them when they crash.


 
 A rather complex application is build from a several layers. A failure 
 on some layer should abort all current processing on that layer, but 
 parent layer could restart the problem layer. So that model with 
 metaprogram/watchdogs or supervisor processes (from Erlang) could be 
 implemented inside a single application with use of safe languages like 

 
 --Regards,
 Yauheni Akhotnikau
Feb 29 2008
parent eao197 <eao197 intervale.ru> writes:
On Fri, 29 Feb 2008 18:42:05 +0300, Russell Lewis  =

<webmaster villagersonline.com> wrote:


 I believe that assert()s are ways to programmatically document things =


 =


 that the program must enforce.  An in() contract on a function is a  =



 statement that says "any code which calls me, but violates this  =



 contract, is buggy."  Exceptions are the way to programmatically handl=


e  =


 unusual conditions in well-ordered ways.


Contract may be considered another way: a function with precodition says=
  =

"I guarantee correct behaviour only when you keeps my precondition".


 So, in your example below, since pack7bitMessage asserts that the  =



 message must be no more than 160 characters, then any code which calle=


d  =


 it must enforce that contract.  Any code which didn't enforce the  =



 contract has a bug.


Yes it is. But a bug in code is not always should lead to abortion of  =

entire application.


 IMHO, if what you want is to have a function which will take input of =


 =


 any length, but refuse to encode things which are longer than 160  =



 characters, then it should be coded as follows:

    byte[] pack7bitMessage( byte[] message )
    {
      if(message.length > 160)
        throw InputTooLongException;

      ... encode ...
    }


Yes that function could be rewritten in such way. But there could be  =

condition when DbC is preferable than defensive programming:
- contracts are part of function prototype, so conract help understandin=
g  =

function behaviour. For example, try look at EiffelBase reference manual=
  =

(http://docs.eiffel.com) -- sometimes bodies of 'require' and 'ensure'  =

give more information that description of a methods;
- contracts could be turned off in release mode when you sure that there=
  =

isn't critical bugs. So, function with contracts:

byte[] pack7bitMessage( byte[] message )
   in {
    assert( message );
    assert( message.length <=3D 160 );
    assert( !is8bitCharFound( message ) );
   }
   body { ... }

will be much faster in speed-critical applications then the function whi=
ch  =

is written in defensive-programming style.


 Finally, let me ask you a question:

 If an failed assert() doesn't represent an unrecoverable logic error, =


 =


 then what does???


As in the case with ordinal exception -- it depends. When you try to add=
 a  =

member into associative array you and get NoMemory exception you don't  =

know is that exception would be unrecoverable or recoverable. If you wri=
te  =

yet another WordCounter example such exception will be fatal for your  =

application. But if you write, for example, some image-transformation  =

program for http://picasa.google.com/ you could simple throw away curren=
t  =

problematic image, clear all resouces which was allocated for that image=
,  =

and go to next image in queue.


 eao197 wrote:

 On Thu, 28 Feb 2008 19:34:45 +0300, Russell Lewis  =





 <webmaster villagersonline.com> wrote:


  It is not necessary to catch AssertError. Sometimes it is necessar=








y  =


 to catch any error. For example, in a HTTP-server you could start  =









 processing of a new request and catch different kinds of errors to =








 =


 make appropriate response:


 I agree that a web server needs to post an appropriate response.  Bu=






t  =


 if an assert() has failed, you don't know if the failure is in your =






 =


 main program, in a library, or maybe even in your network code.  In =






 =


 that case, you can't really rely on your program to keep working  =







 correctly, and the only sane solution would be to restart it.


  Violation of contract is not a sign of unrecoverable failure of the =




 =


 program, expecially for preconditions. Quite the contrary contracts  =





 help detect unappropriate conditions at earlier stages.
  For example, SMS body in 140 bytes long. 7-bit message could be up t=




o  =


 160 symbols, packed into 140 bytes SMS body. You could have 7-bit  =





 message packing functions with precondition:
  byte[] pack7bitMessage( byte[] message )
   in { assert( message.length <=3D 160 ); }
   body { ... }
  When pack7bitMessage receives message which is longer than 160 symbo=




ls  =


 there isn't any sign of unrecoverable error. For example, the too lon=




g  =


 body of message may be received from SMPP PDU submit_sm from a ESME w=




ho  =


 simply had made an error in their PDU. It may be a sign of presence o=




f  =


 error in your code for submit_sm parsing (length of SMS body not  =





 checked) but there nothing fatal for whole application.
  And that is a situation where application abort and restart don't  =





 solve a problem -- ESME simply repeat the problem submit_sm after  =





 server restart and server go down again and so on.


 My argument, then, is that you need a metaprogram or "watchdog" (suc=






h  =


 as the init process in *NIX, or maybe just a "web server launcher") =






 =


 which manages the server programs and restarts them when they crash.=







  A rather complex application is build from a several layers. A failu=




re  =


 on some layer should abort all current processing on that layer, but =




 =


 parent layer could restart the problem layer. So that model with  =





 metaprogram/watchdogs or supervisor processes (from Erlang) could be =




 =


 implemented inside a single application with use of safe languages li=




ke  =



  --Regards,
 Yauheni Akhotnikau






-- =

Regards,
Yauheni Akhotnikau
Feb 29 2008
prev sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
eao197 wrote:

 On Thu, 28 Feb 2008 19:34:45 +0300, Russell Lewis 
 <webmaster villagersonline.com> wrote:
 

  It is not necessary to catch AssertError. Sometimes it is necessary 
 to catch any error. For example, in a HTTP-server you could start 
 processing of a new request and catch different kinds of errors to 
 make appropriate response:


 I agree that a web server needs to post an appropriate response.  But 
 if an assert() has failed, you don't know if the failure is in your 




...

 
 For example, SMS body in 140 bytes long. 7-bit message could be up to 
 160 symbols, packed into 140 bytes SMS body. You could have 7-bit 
 message packing functions with precondition:
 
 byte[] pack7bitMessage( byte[] message )
   in { assert( message.length <= 160 ); }
   body { ... }
 


...

I think you are misunderstanding the purpose of assert and of 
other conditions.  Remember, these statements will be stripped 
out of the code when it is compiled for release.  As such, 
they should only be used to detect conditions which are 
genuine errors.  The reason that they might be cause would be 
so that the actual error could be raised from the location 
where the error is generated, rather than from where it was 
detected.

In Other Words:  Don't use contracts as a substitute for 
conditionals, even if the conditional *would* raise an 
exception.  They aren't the same concept.

Now I'll grant that in some languages the two concepts are 
fused, and conditionals are constrained to do double duty as 
exceptions.  Even in those languages, however, there is often 
a flag that will cause assertions to become null statements 
when compiled with optimization (or without debugging turned on).
[N.B.:  The prior paragraph is based on certain dialects of C 
or C++ that are over a decade old now.  It may not apply to 
currently extant compilers.]
Feb 29 2008
prev sibling parent Russell Lewis <webmaster villagersonline.com> writes:
The example would be (reasonably) compilable, without whole-program 
knowledege, if foo() had an in{} condition which asserted that the index 
was valid.

It would be possible (though not trivial) for the compiler to say "ah, 
provided that the caller follows the in{} contract, this function cannot 
throw an exception."

Walter Bright wrote:

 Ary Borenszweig wrote:

 Does this mean this will not compile:

 int foo(int[] someArray, int someIndex) nothrow {
     return someArray[someIndex];
 }

 but this will:

 int foo(int[] someArray, int someIndex) nothrow {
     if (someIndex < someArray.length) {
         return someArray[someIndex];
     } else {
         return -1;
     }
 }


 
 I don't know yet. But the idea is to do static checking of what can throw.
Feb 25 2008
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Ary Borenszweig wrote:


 Walter Bright escribió:

 Graham St Jack wrote:

 It would work just like "nothrow" does for C++.


 Just checking - I hope this means that if a nothrow function actually
 DID try to throw an exception (by calling something that throws),
 compiler-
 generated code would trap it and terminate the program with an error
 message?


 
 No, but it will try to detect errors at compile time.


 
 Does this mean this will not compile:
 
 int foo(int[] someArray, int someIndex) nothrow {
 return someArray[someIndex];
 }


I sincerely hope that design by contract will allow for us to iron out
issues like this.  Ideally, something very near the following should be
valid:

int foo(int[] someArray, int someIndex) nothrow
in{
  assert(someIndex < someArray.length && someIndex >= 0);
}
body{
  return someArray[someIndex];
}

I've always hoped for in and out contracts to be usable by the compiler for
optimization (such as verifying nothrow).  I know this looks like it
violates the nothrow (when not compiled with the release flag), but I'm ok
with that for code I'm debugging.  Printing the failed assert and ending
the program is more useful to me anyway.
Feb 25 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:

 Graham St Jack wrote:

 It would work just like "nothrow" does for C++.


 Just checking - I hope this means that if a nothrow function actually 
 DID try to throw an exception (by calling something that throws), 
 compiler-
 generated code would trap it and terminate the program with an error 
 message?


 
 No, but it will try to detect errors at compile time.


And nothrow will be a valid part of a delegate signature, correct? So I 
can use nothrow with delegates.

Nothrow is especially tricky because it doesn't require a function call 
to get an exception. But those cases are relatively rare.
Feb 25 2008
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 20 de febrero a las 18:58 me escribiste:

 Graham St Jack wrote:

It is also very helpful when writing code to know that a function you are
calling won't 
throw an exception - it means you have three kinds of functions: those that
don't throw, 
those with comments telling you what they throw, and those that you need to fix
the 
comments for.


 
 Experience with this indicates that it is impractical to specify what
exceptions a 
 function may throw. The only practical states to specify are:
 
 1) does not throw
 2) always throws
 3) might throw
 
 What is thrown is not reliably computable. For example:
 
 import foo;
 void test()
 {
     foo.bar();
 }
 
 What exceptions does test() throw? That would require knowledge of the import
foo, which 
 is not necessarily knowable and can change over time.


And what's the difference with nothrow? foo.bar's nothrow-ness "is not
necessarily knowable and can change over time". It's exactly the same,
you're just limiting the way you specify exceptions, but you are specifing
them after all.

This is like limiting C++ exception specification to nothing or an empty
throw() qualifier.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Hace diez años tenía una visión
Pero nadie más la vió y hoy sigo pidiendo perdón
Feb 25 2008
parent Georg Wrede <georg nospam.org> writes:
Leandro Lucarella wrote:

 Walter Bright, el 20 de febrero a las 18:58 me escribiste:
 

Graham St Jack wrote:


It is also very helpful when writing code to know that a function you are
calling won't 
throw an exception - it means you have three kinds of functions: those that
don't throw, 
those with comments telling you what they throw, and those that you need to fix
the 
comments for.


Experience with this indicates that it is impractical to specify what
exceptions a 
function may throw. The only practical states to specify are:

1) does not throw
2) always throws
3) might throw

What is thrown is not reliably computable. For example:

import foo;
void test()
{
    foo.bar();
}

What exceptions does test() throw? That would require knowledge of the import
foo, which 
is not necessarily knowable and can change over time.


 
 
 And what's the difference with nothrow? foo.bar's nothrow-ness "is not
 necessarily knowable and can change over time". It's exactly the same,
 you're just limiting the way you specify exceptions, but you are specifing
 them after all.
 
 This is like limiting C++ exception specification to nothing or an empty
 throw() qualifier.


Of course, there should be a Nothrow-offense exception. Right?!!

Such an exception would be thrown whenever a function that's declared as 
not throwing an exception actually does throw one.
Mar 03 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Extrawurst wrote:

 yeah but what happend to the express-such-things-via-documention policy 
 to keep syntax simple ?


It looks like the bane of all my Java existence, exception 
specifications, are back, under the mask of "optimization" this time. 
But, unlike const, you're not required to use nothrow to make use of 
libraries which use it, so it's up to you to ignore it or not.
Feb 21 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Robert Fraser escribió:

 Extrawurst wrote:

 yeah but what happend to the express-such-things-via-documention 
 policy to keep syntax simple ?


 
 It looks like the bane of all my Java existence, exception 
 specifications, are back, under the mask of "optimization" this time. 
 But, unlike const, you're not required to use nothrow to make use of 
 libraries which use it, so it's up to you to ignore it or not.


In fact, it's just serves as a hint to the compiler, right? Like 
"inline" in C?
Feb 21 2008
parent lutger <lutger.blijdestijn gmail.com> writes:
Ary Borenszweig wrote:


 Robert Fraser escribió:

 Extrawurst wrote:

 yeah but what happend to the express-such-things-via-documention
 policy to keep syntax simple ?


 
 It looks like the bane of all my Java existence, exception
 specifications, are back, under the mask of "optimization" this time.
 But, unlike const, you're not required to use nothrow to make use of
 libraries which use it, so it's up to you to ignore it or not.


 
 In fact, it's just serves as a hint to the compiler, right? Like
 "inline" in C?


In the slides from the conference it is mentioned that nothrow is statically
checked by the compiler. 

I think it's not only about optimization, it's also useful for writing
exception-safe code.
Feb 21 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:

 Extrawurst wrote:

 yeah but what happend to the express-such-things-via-documention 
 policy to keep syntax simple ?


 
 It looks like the bane of all my Java existence, exception 
 specifications, are back, under the mask of "optimization" this time. 
 But, unlike const, you're not required to use nothrow to make use of 
 libraries which use it, so it's up to you to ignore it or not.


The downsides of general exception specifications are not shared by nothrow.
Feb 21 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:

 http://www.digitalmars.com/d/2.0/changelog.html
  Now allow static arrays to be lvalues.


Cool, and about time! :) I've just tried it out and it's so much more 
natural.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Feb 28 2008