http://ftp.digitalmars.com/dmd2beta.zip

I think it's time we officially started the beta process. Yes, I need to start a 2.063 branch.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/14/2013 10:05 PM, Walter Bright wrote:
> http://ftp.digitalmars.com/dmd2beta.zip
>
> I think it's time we officially started the beta process. Yes, I need to start a 2.063 branch.


geez, that should be 2.063
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

No 2.063 branch for me here : https://github.com/D-Programming-Language/dmd/branches

On Wed, May 15, 2013 at 8:07 AM, Walter Bright <walter@digitalmars.com> wrote:
>
> On 5/14/2013 10:05 PM, Walter Bright wrote:
>>
>> http://ftp.digitalmars.com/dmd2beta.zip
>>
>> I think it's time we officially started the beta process. Yes, I need to start a 2.063 branch.
>
>
>
> geez, that should be 2.063
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

This absolutely must not be released in this form.
This has a silent, massive breaking change --
struct  S { const int x = 7; }
Previously, x was just a manifest constant. Now, S now has an int inside
every instance.
It's OK to turn that into an error. It's not OK to silently change the
meaning of existing code.
Especially in such a radical manner.





On 15 May 2013 09:09, Михаил Страшун <m.strashun@gmail.com> wrote:

> No 2.063 branch for me here : https://github.com/D-Programming-Language/dmd/branches
>
> On Wed, May 15, 2013 at 8:07 AM, Walter Bright <walter@digitalmars.com> wrote:
> >
> > On 5/14/2013 10:05 PM, Walter Bright wrote:
> >>
> >> http://ftp.digitalmars.com/dmd2beta.zip
> >>
> >> I think it's time we officially started the beta process. Yes, I need to start a 2.063 branch.
> >
> >
> >
> > geez, that should be 2.063
> >
> > _______________________________________________
> > dmd-beta mailing list
> > dmd-beta@puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/dmd-beta
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

2013/5/15 Don Clugston <dclugston@gmail.com>

> This absolutely must not be released in this form.
> This has a silent, massive breaking change --
> struct  S { const int x = 7; }
> Previously, x was just a manifest constant. Now, S now has an int inside
> every instance.
> It's OK to turn that into an error. It's not OK to silently change the
> meaning of existing code.
> Especially in such a radical manner.
>

It will be properly documented at the top of the language changes. https://github.com/D-Programming-Language/d-programming-language.org/pull/303/files#L0R60

Certainly it will change object layout silently. But semantic meaning would
not be changed in most cases, So just once full-recompilation would be
necessary.
I think that it is not a problem which deserves to reject the code by
compilation error.

Kenji Hara

It is not an error (actually, old behavior smells like a bug for sure), but it is incredibly inconvenient breaking change for any code that relies on exact object layout and such code is not that rare. Some better transition path is really desired here.

On Wed, May 15, 2013 at 2:54 PM, Kenji Hara <k.hara.pg@gmail.com> wrote:
> 2013/5/15 Don Clugston <dclugston@gmail.com>
>>
>> This absolutely must not be released in this form.
>> This has a silent, massive breaking change --
>> struct  S { const int x = 7; }
>> Previously, x was just a manifest constant. Now, S now has an int inside
>> every instance.
>> It's OK to turn that into an error. It's not OK to silently change the
>> meaning of existing code.
>> Especially in such a radical manner.
>
>
> It will be properly documented at the top of the language changes. https://github.com/D-Programming-Language/d-programming-language.org/pull/303/files#L0R60
>
> Certainly it will change object layout silently. But semantic meaning would
> not be changed in most cases, So just once full-recompilation would be
> necessary.
> I think that it is not a problem which deserves to reject the code by
> compilation error.
>
> Kenji Hara
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 15 May 2013 13:54, Kenji Hara <k.hara.pg@gmail.com> wrote:

> 2013/5/15 Don Clugston <dclugston@gmail.com>
>
>> This absolutely must not be released in this form.
>> This has a silent, massive breaking change --
>> struct  S { const int x = 7; }
>> Previously, x was just a manifest constant. Now, S now has an int inside
>> every instance.
>> It's OK to turn that into an error. It's not OK to silently change the
>> meaning of existing code.
>> Especially in such a radical manner.
>>
>
> It will be properly documented at the top of the language changes.
>
> https://github.com/D-Programming-Language/d-programming-language.org/pull/303/files#L0R60
>
> Certainly it will change object layout silently. But semantic meaning would not be changed in most cases,
>

Sorry, but that is absolute rubbish.
(1) Any existing instance of this silently introduces a *severe*
performance bug.
(2) Any storage of this struct silently fails.

For example, for us, we serialize objects and store them in a database. This now fails because they are the wrong size.

I can accept the consistency argument against the existing behaviour. However, I cannot imagine a scenario where this new behaviour would be desirable. Are there any use cases?


So just once full-recompilation would be necessary.
>

No, this is wrong. Every existing instance must be changed. And there is no way to find them.

Seriously, this is one of the most breaking changes I can ever remember in the history of D.

Consistency is important. struct S { enum x = 7; } _should_ be
different from struct S { const x = 7; }
Worst part here is not the change itself but that compiler provides no
help in finding all broken places. And that is intolerable.

On Wed, May 15, 2013 at 3:52 PM, Don Clugston <dclugston@gmail.com> wrote:
> On 15 May 2013 13:54, Kenji Hara <k.hara.pg@gmail.com> wrote:
>>
>> 2013/5/15 Don Clugston <dclugston@gmail.com>
>>>
>>> This absolutely must not be released in this form.
>>> This has a silent, massive breaking change --
>>> struct  S { const int x = 7; }
>>> Previously, x was just a manifest constant. Now, S now has an int inside
>>> every instance.
>>> It's OK to turn that into an error. It's not OK to silently change the
>>> meaning of existing code.
>>> Especially in such a radical manner.
>>
>>
>> It will be properly documented at the top of the language changes.
>>
>> https://github.com/D-Programming-Language/d-programming-language.org/pull/303/files#L0R60
>>
>> Certainly it will change object layout silently. But semantic meaning would not be changed in most cases,
>
>
> Sorry, but that is absolute rubbish.
> (1) Any existing instance of this silently introduces a *severe* performance
> bug.
> (2) Any storage of this struct silently fails.
>
> For example, for us, we serialize objects and store them in a database. This now fails because they are the wrong size.
>
> I can accept the consistency argument against the existing behaviour. However, I cannot imagine a scenario where this new behaviour would be desirable. Are there any use cases?
>
>
>> So just once full-recompilation would be necessary.
>
>
> No, this is wrong. Every existing instance must be changed. And there is no way to find them.
>
> Seriously, this is one of the most breaking changes I can ever remember in the history of D.
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

> I can accept the consistency argument against the existing behaviour. However, I cannot imagine a scenario where this new behaviour would be
desirable. Are there any use cases?

import std.typecons;
void main()
{
    alias Typedef!(immutable int, 1) MyInt;
    MyInt x;  // did not work witn 2.062 and earlier
}

In D2, 'immutabe' and 'const' are type qualifier, and it should not have "manifest constant" meaning. That is completely different from the 'const' in D1. Yes' this would be a big change for someone, because it was the long term bug bug FROM THE BEGINNING OF D2. We must fix the bug AS FAR AS POSSIBLE FAST. It's a time now.

Kenji Hara


2013/5/15 Don Clugston <dclugston@gmail.com>

> On 15 May 2013 13:54, Kenji Hara <k.hara.pg@gmail.com> wrote:
>
>> 2013/5/15 Don Clugston <dclugston@gmail.com>
>>
>>> This absolutely must not be released in this form.
>>> This has a silent, massive breaking change --
>>> struct  S { const int x = 7; }
>>> Previously, x was just a manifest constant. Now, S now has an int inside
>>> every instance.
>>> It's OK to turn that into an error. It's not OK to silently change the
>>> meaning of existing code.
>>> Especially in such a radical manner.
>>>
>>
>> It will be properly documented at the top of the language changes.
>>
>> https://github.com/D-Programming-Language/d-programming-language.org/pull/303/files#L0R60
>>
>> Certainly it will change object layout silently. But semantic meaning would not be changed in most cases,
>>
>
> Sorry, but that is absolute rubbish.
> (1) Any existing instance of this silently introduces a *severe*
> performance bug.
> (2) Any storage of this struct silently fails.
>
> For example, for us, we serialize objects and store them in a database. This now fails because they are the wrong size.
>
> I can accept the consistency argument against the existing behaviour. However, I cannot imagine a scenario where this new behaviour would be desirable. Are there any use cases?
>
>
>  So just once full-recompilation would be necessary.
>>
>
> No, this is wrong. Every existing instance must be changed. And there is no way to find them.
>
> Seriously, this is one of the most breaking changes I can ever remember in the history of D.
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>

On May 15, 2013, at 8:52 AM, Don Clugston <dclugston@gmail.com> wrote:

> On 15 May 2013 13:54, Kenji Hara <k.hara.pg@gmail.com> wrote:
> 
> 
>> So just once full-recompilation would be necessary.
> 
> No, this is wrong. Every existing instance must be changed. And there is no way to find them.

When globals started defaulting to TLS, dmd got a compilation switch to identify impacted code. Would a similar solution work here?