Hi all.

I recently downloaded and installed version 2.063.2, but now I see the current version is listed as 2.063. Is this is an error?

Also, does anyone know if a new edition of "The D Programming Language" is planned in the relatively near future?

Thanks,

Caitlin

On Saturday, July 06, 2013 03:22:57 Caitlin wrote:
> Hi all.
> 
> I recently downloaded and installed version 2.063.2, but now I see the current version is listed as 2.063. Is this is an error?

The current release is 2.063.2, but it's the first time that we've actually released point releases like that, so there are likely to be places saying 2.063 instead of 2.063.2.

> Also, does anyone know if a new edition of "The D Programming Language" is planned in the relatively near future?

No, but what's there is mostly correct. There are a few things that aren't yet implemented quite as described in TDPL (e.g. we don't have multiple alias this-es yet, and synchronized still is at a function-level instead of at a class level like TDPL describes), and there are probably a couple of things that have changed since the book was released (e.g. the book describes strongly pure functions, but we now also have weakly pure functions), but it's almost all correct. So, while I'm sure that there will be a new edition eventually, there's not a lot of point in releasing another one at this point.

- Jonathan M Davis

On Saturday, 6 July 2013 at 01:30:49 UTC, Jonathan M Davis wrote:
> No, but what's there is mostly correct. There are a few things that aren't yet
> implemented quite as described in TDPL (e.g. we don't have multiple alias
> this-es yet, and synchronized still is at a function-level instead of at a
> class level like TDPL describes), and there are probably a couple of things
> that have changed since the book was released (e.g. the book describes
> strongly pure functions, but we now also have weakly pure functions), but it's
> almost all correct. So, while I'm sure that there will be a new edition
> eventually, there's not a lot of point in releasing another one at this point.


Are the differences from TDPL documented anywhere? Might be worth having a page on the wiki or the main website.

On Saturday, July 06, 2013 09:12:55 Joseph Rushton Wakeling wrote:
> Are the differences from TDPL documented anywhere?

Not that I'm aware of. And I'd have to read it again to compile a full list, though I could probably come up with most of them off the top of my head.

- Jonathan M Davis

On Saturday, 6 July 2013 at 07:18:03 UTC, Jonathan M Davis wrote:
> On Saturday, July 06, 2013 09:12:55 Joseph Rushton Wakeling wrote:
>> Are the differences from TDPL documented anywhere?
>
> Not that I'm aware of. And I'd have to read it again to compile a full list, though I could probably come up with most of them
> off the top of my head.
>
> - Jonathan M Davis

I read TDPL again quite recently. And although it's missing a bunch of language features and there's a bunch of typos, I can't think of any language feature mentioned there that's changed since then (and I probably just don't know about it). So, I'd be interested in seeing that list.

On Saturday, 6 July 2013 at 07:18:03 UTC, Jonathan M Davis wrote:
> On Saturday, July 06, 2013 09:12:55 Joseph Rushton Wakeling wrote:
>> Are the differences from TDPL documented anywhere?
>
> Not that I'm aware of. And I'd have to read it again to compile a full list,
> though I could probably come up with most of them off the top of my head.
>
> - Jonathan M Davis

Depends what you mean by "the differences"? In any case, there is an erratum available:
http://erdani.com/tdpl/errata/

Any piece of code that doesn't compile, chances are there is a correction here.

On Saturday, July 06, 2013 09:43:24 TommiT wrote:
> On Saturday, 6 July 2013 at 07:18:03 UTC, Jonathan M Davis wrote:
> > On Saturday, July 06, 2013 09:12:55 Joseph Rushton Wakeling
> > 
> > wrote:
> >> Are the differences from TDPL documented anywhere?
> > 
> > Not that I'm aware of. And I'd have to read it again to compile a full list, though I could probably come up with most of them off the top of my head.
> > 
> > - Jonathan M Davis
> 
> I read TDPL again quite recently. And although it's missing a bunch of language features and there's a bunch of typos, I can't think of any language feature mentioned there that's changed since then (and I probably just don't know about it). So, I'd be interested in seeing that list.

The main one that's changed is pure. TDPL basically describes strong purity, whereas we now also have weak purity.

The main two that simply haven't yet been implemented as described are multiple alias this-es, and synchronized classes.

Some of what TDPL says about shared is wrong (e.g. about it adding write barriers), but exactly what we're going to do about shared at this point is up for debate. We need it, and we're going to have it, but some of the details need to be further ironed out (e.g. it's unlikely that it'll ever have write barriers, because that would be too expensive and IIRC isn't even portable outside of x86/x86_64). As part of that, synchronized may or may not end up quite as described in TDPL.

Beyond that, I'd probably have to re-read the book. I don't think that there are any other major differences, but there may be some minor ones. Most of those should have been caught by the errata though.

- Jonathan M Davis

On Saturday, July 06, 2013 01:03:01 Jonathan M Davis wrote:
> The main one that's changed is pure. TDPL basically describes strong purity, whereas we now also have weak purity.

However, we may end up with a few more changes to it within the next few months, depending on how quickly we resolve some of our outstanding issues.

1. If we ever manage to remove toString, toHash, opEquals, and opCmp from Object like we decided to do, there will be a few more things in TDPL which will be wrong.

2. @property still needs to be sorted out, and we don't know quite what properties are going to look like when we're done.

3. As I mentioned, shared still needs to be sorted out.

4. We might be changing it so that member functions are virtual by default (Walter seems to have been recently convinced that this would be the right thing to do, but AFAIK, he never decided that we were definitely going to do it). And that would invalidate parts of TDPL.

5. It looks like we're not going to be doing anything with ref which would make it contradict TDPL, but there's still some debate as to what exactly we're going to do with ref and @safe (Walter has a solution, but some people object to it). And that may have an effect on the auto ref issue.

There are probably others as well, but we do risk making some changes in the near future in order to resolve some longstanding issues, and some of them would make TDPL less accurate. Thus far though, most of the changes post-TDPL have been purely additive and don't contradict it at all.

> The main two that simply haven't yet been implemented as described are

Ah, there's also auto ref. The way TDPL describes it, it should work on the parameters of non-templated functions as well as templated ones, but it has yet to be implemented that way. And there's some debate as to what to do about that.

And I'm not sure if the stuff with private and interfaces that TDPL describes has been implemented yet. So, that might increase the number of not fully implemented items.

- Jonathan M Davis

On Saturday, 6 July 2013 at 08:14:06 UTC, Jonathan M Davis wrote:
> Ah, there's also auto ref. The way TDPL describes it, it should work on the
> parameters of non-templated functions as well as templated ones, but it has
> yet to be implemented that way. And there's some debate as to what to do about
> that.

TDPL doesn't mention auto ref at all (not even as a function return type). The spec talks about auto ref as both function return type and parameter type for function templates. So, it seems auto ref as parameter for regular functions doesn't seem to documented anywhere (which is good if it's not ready yet).

> 4. We might be changing it so that member functions are virtual by default

You mean final by default, don't you? AFAIK they are currently virtual by default.