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

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

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.

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

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.

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

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

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

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.

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.