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

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
>

> 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

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

> 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.

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

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

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

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

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