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

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

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

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.

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

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.

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.

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?

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.

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.