== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Mostly bug fixing. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.032.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.016.zip

I don't suppose there's any chance that bugzilla 288 could be fixed
in 1.0 as well?  I know it's a breaking change from a code perspective,
but it was clearly considered a bug in 1.0, and it makes maintaining
cross-compatible code between 1.0 and 2.0 difficult at best.


Sean

Lars Ivar Igesund wrote:
> Lars Ivar Igesund wrote:
>  
>> It would be nice if the release process could stop this from happening.
>  I wrote a short piece on this topic : http://larsivi.net/node/114
> 
> As it is, I will recommend against using this release for Tango users.
> 

After reading larsivi's blog post, I can only say I couldn't agree more!
I would personally not mind getting a release candidate and running it through some dstress/tango testing. Obviously this is not done already...

I would probably even try merging the changes into LLVMDC and see if anything shows up there.

Consider it an offer!

On Wed, 09 Jul 2008 21:03:38 +0400, Tomas Lindquist Olsen <tomas@famolsen.dk> wrote:

> Lars Ivar Igesund wrote:
>> Lars Ivar Igesund wrote:
>>
>>> It would be nice if the release process could stop this from happening.
>>  I wrote a short piece on this topic : http://larsivi.net/node/114
>>  As it is, I will recommend against using this release for Tango users.
>>
>
> After reading larsivi's blog post, I can only say I couldn't agree more!
> I would personally not mind getting a release candidate and running it through some dstress/tango testing. Obviously this is not done already...
>
> I would probably even try merging the changes into LLVMDC and see if anything shows up there.
>
> Consider it an offer!

I don't agree, it's useless to have a group of reviewers for DMD releases *unless* you are targeting a simultaneous DMD/Tango or DMD/GDC or DMD/<something-else> release. Now you know that stuff doesn't compile, and what? The breaking changes won't be reverter anyway, the bugs weren't fixed just to know that this bugfix breaks existing code, although I understand that it's frustrating to see that your code doesn't compile anymore. Just continue using DMD1.031, this release doesn't introduce any great features anyway.

Koroskin Denis wrote:

> On Wed, 09 Jul 2008 21:03:38 +0400, Tomas Lindquist Olsen <tomas@famolsen.dk> wrote:
> 
>> Lars Ivar Igesund wrote:
>>> Lars Ivar Igesund wrote:
>>>
>>>> It would be nice if the release process could stop this from happening.
>>>  I wrote a short piece on this topic : http://larsivi.net/node/114
>>>  As it is, I will recommend against using this release for Tango users.
>>>
>>
>> After reading larsivi's blog post, I can only say I couldn't agree more! I would personally not mind getting a release candidate and running it through some dstress/tango testing. Obviously this is not done already...
>>
>> I would probably even try merging the changes into LLVMDC and see if anything shows up there.
>>
>> Consider it an offer!
> 
> I don't agree, it's useless to have a group of reviewers for DMD releases *unless* you are targeting a simultaneous DMD/Tango or DMD/GDC or DMD/<something-else> release. Now you know that stuff doesn't compile, and what? The breaking changes won't be reverter anyway, the bugs weren't fixed just to know that this bugfix breaks existing code, although I understand that it's frustrating to see that your code doesn't compile anymore. Just continue using DMD1.031, this release doesn't introduce any great features anyway.

I agree that there is no particular need to upgrade, although new DMD releases tend to have bugfixes that are important to Tango users. Furthermore, D users expect any D 1.0 library to work with the next DMD 1.0xx compiler release, it is a stable branch after all. When this does not happen, i.e the compiler has a breaking change, there is some furious work at our end to figure out what the heck is wrong, with potentially quite a few requests and pings from the users (I speak from experience).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Sean Kelly wrote:
> I don't suppose there's any chance that bugzilla 288 could be fixed
> in 1.0 as well?  I know it's a breaking change from a code perspective,
> but it was clearly considered a bug in 1.0, and it makes maintaining
> cross-compatible code between 1.0 and 2.0 difficult at best.

The problem is it's a breaking change.

Max Samukha wrote:
> Change log page for D 1.0 is also broken

Not no more!

Walter Bright wrote:

> Sean Kelly wrote:
>> I don't suppose there's any chance that bugzilla 288 could be fixed
>> in 1.0 as well?  I know it's a breaking change from a code perspective,
>> but it was clearly considered a bug in 1.0, and it makes maintaining
>> cross-compatible code between 1.0 and 2.0 difficult at best.
> 
> The problem is it's a breaking change.

I'm not convinced that is worrying you ;)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

bearophile wrote:
> It seems my libs work again with this version (1.032), I've had to
> change just two things in a 10-minutes debugging, than you. I have
> had to change this line (inside a function template, T is a type,
> often it's an array, but it can be a void array too):
> 
> static if(!is( typeof(T) == void[0] )) { To: static if(!is( T ==
> void[0] )) {

Yes, that bug fix caught several such instances in my code, too.

> At a first test, it seems the compiled executables are 2-3+ times
> bigger than the ones produced by 1.029.

Hmm, haven't noticed that.

Sean Kelly wrote:
> While it's invalid to return a static array from a function, it does seem like
> this could have undesired consequences:
> 
>     T fn(T)( T val ) { return val; }
> 
> Shouldn't the above be valid for all types?

Yes, but returning static arrays is not allowed.

Lars Ivar Igesund wrote:
> I agree that there is no particular need to upgrade, although new DMD
> releases tend to have bugfixes that are important to Tango users.
> Furthermore, D users expect any D 1.0 library to work with the next DMD
> 1.0xx compiler release, it is a stable branch after all. When this does not
> happen, i.e the compiler has a breaking change, there is some furious work
> at our end to figure out what the heck is wrong, with potentially quite a
> few requests and pings from the users (I speak from experience).

I apologize for that.