[dmd-beta] dmd 2.064 beta take 2

Don Clugston dclugston at gmail.com
Wed May 15 07:01:02 PDT 2013


On 15 May 2013 15:17, Kenji Hara <k.hara.pg at 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 at gmail.com>
>
>> On 15 May 2013 13:54, Kenji Hara <k.hara.pg at gmail.com> wrote:
>>
>>> 2013/5/15 Don Clugston <dclugston at 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 at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>>
>
>
> _______________________________________________
> dmd-beta mailing list
> dmd-beta at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-beta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20130515/88a4c26b/attachment-0001.html>


More information about the dmd-beta mailing list