On 15 May 2013 15:17, Kenji Hara <[email protected]> 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 <[email protected]> > >> On 15 May 2013 13:54, Kenji Hara <[email protected]> wrote: >> >>> 2013/5/15 Don Clugston <[email protected]> >>> >>>> 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 >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/dmd-beta >> > > > _______________________________________________ > dmd-beta mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-beta >
_______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
