May 14, 2013 [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
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 |
May 14, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Михаил Страшун Attachments:
| 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
>
|
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston Attachments:
| 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 |
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 |
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara Attachments:
| 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. |
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | 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 |
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston Attachments:
| > 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 > |
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston Attachments:
| 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?
|
Copyright © 1999-2021 by the D Language Foundation