May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | On 5/15/13, Don Clugston <dclugston@gmail.com> wrote: > For example, for us, we serialize objects and store them in a database. This now fails because they are the wrong size. Why didn't you use "static const" to begin with? _______________________________________________ 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 15:17, Kenji Hara <k.hara.pg@gmail.com> wrote: > > 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. > I agree with that, but... I think the new behaviour is a misfeature, and nothing more. It makes no sense to store a value in each struct, when the value is exactly the same every time. My assert: 100% of these cases are bugs. Having looked at the code for Typedef, I think it's a bug. It's unnecessarily inefficient. > 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 >> > > > _______________________________________________ > 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 | > I agree with that, but... > I think the new behaviour is a misfeature, and nothing more. It makes no > sense to store a value in each struct, when the value is exactly the same > every time. > My assert: 100% of these cases are bugs. It is not: struct S { const int x; this(int ax) { x = ax; } } void main() { import std.stdio; writeln(S(41)); writeln(S(42)); } You kind of propose that "const int" to be a completely different type depending on initialiser. It is horrible. _______________________________________________ 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 Andrej Mitrovic | I guess D1 heritage. The fact is - it does not matter. Silent breakage is silent breakage and it is irrelevant if original code was bad or invalid. It compiled before, it doesn't now - compiler MUST provide a soft transition path, for example, via compiler switch. If this is even questioned, we are really far from any stability demands. On Wed, May 15, 2013 at 4:59 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote: > On 5/15/13, Don Clugston <dclugston@gmail.com> wrote: >> For example, for us, we serialize objects and store them in a database. This now fails because they are the wrong size. > > Why didn't you use "static const" to begin with? > _______________________________________________ > 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:
| > You kind of propose that "const int" to be a completely different type depending on initialiser. It is horrible.
>
I have not said that. I've asserted that const member with an initializer,
when inside a struct, is ALWAYS a bug.
I agree that we need to get rid of the existing behaviour. But I argue it
should simply be an error, rather than replacing it with a misfeature.
|
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | Don't forget about S.init - const element initializer changes it and makes sense in that way. So you may have both cont element with initializer and constructor that changes it later. It is completely legitimate D code, despite the fact I can't imagine any use case for it now. On Wed, May 15, 2013 at 5:11 PM, Don Clugston <dclugston@gmail.com> wrote: > >> You kind of propose that "const int" to be a completely different type depending on initialiser. It is horrible. > > > I have not said that. I've asserted that const member with an initializer, > when inside a struct, is ALWAYS a bug. > I agree that we need to get rid of the existing behaviour. But I argue it > should simply be an error, rather than replacing it with a misfeature. > > _______________________________________________ > 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 Jason House Attachments:
| 2013/5/15 Jason House <jason.james.house@gmail.com> > 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? > Good idea! I've implemented it. https://github.com/D-Programming-Language/dmd/pull/2039 Kenji Hara |
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kenji Hara | Awesome, thanks! By the way, what about generalizing this approach? Making generic parameter, like "--transition=<bug id>" that will get new transition warnings added for every new breaking bug fix. Adding separate flag for very case does not really scale well. On Wed, May 15, 2013 at 5:28 PM, Kenji Hara <k.hara.pg@gmail.com> wrote: > Good idea! I've implemented it. https://github.com/D-Programming-Language/dmd/pull/2039 > > 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 Don Clugston Attachments:
| 2013/5/15 Don Clugston <dclugston@gmail.com>
> But I argue it should simply be an error, rather than replacing it with a misfeature.
>
I cannot understand why you argue the new behavior is a 'mesfeature'.
Const/immutable variable type and specifying variable initializer
should not interfere with each other.
Under the old behavior, following code never work.
struct S {
immutable int x = 1;
this(int x) { this.x = x; }
}
void main() {
S s1; // default construction
assert(s1.x == 1);
S s2 = S(2); //
assert(s2.x == 2);
}
I think this is necessary to make non-mutable object field more usable.
Kenji Hara
|
May 15, 2013 Re: [dmd-beta] dmd 2.064 beta take 2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | On 5/15/13 10:01 AM, Don Clugston wrote: > I think the new behaviour is a misfeature, and nothing more. It makes no > sense to store a value in each struct, when the value is exactly the > same every time. Consider: struct A { const int x = 7; this(int y) { x = y; } } Andrei _______________________________________________ dmd-beta mailing list dmd-beta@puremagic.com http://lists.puremagic.com/mailman/listinfo/dmd-beta |
Copyright © 1999-2021 by the D Language Foundation