This code compile fine under both versions:

dmd (2.066, -debug -d):
OK

dmd (2.067, -debug -d):
core.exception.AssertError@main.d(24): Assertion failure
----------------
./main() [0x46413f]
./main(_Dmain+0x86) [0x449996]
./main(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) [0x467d53]
./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x467ca6]
./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x30) [0x467d0c]
./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x467ca6]
./main(_d_run_main+0x1dc) [0x467c20]
./main(main+0x17) [0x464157]
/usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f4b8d440800]

On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:
static struct S
{
     immutable FLAG_ON = 1;
     immutable FLAG_GPRS = 2;
     immutable FLAG_HIDDEN = 4;
     ubyte flags;
     ubyte value;

     bool isFlagSet(int flag)
     {
         return flags && flag == flag;
     }
}

void main(string[ ] args)
{
     auto someData = [0x01, 0x10, 0x02, 0x16, 0x04, 0x08];
     auto countS = someData.length / S.sizeof;

     S[] sArray = (cast(S*)someData.ptr)[0 .. countS];
     assert(sArray.length == 3);
}

On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:
> This code compile fine under both versions:
>
> dmd (2.066, -debug -d):
> OK
>
> dmd (2.067, -debug -d):
> core.exception.AssertError@main.d(24): Assertion failure
> ----------------
> ./main() [0x46413f]
> ./main(_Dmain+0x86) [0x449996]
> ./main(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) [0x467d53]
> ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x467ca6]
> ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x30) [0x467d0c]
> ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x467ca6]
> ./main(_d_run_main+0x1dc) [0x467c20]
> ./main(main+0x17) [0x464157]
> /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f4b8d440800]

What code?

The worst thing is a runtime breakage and there is almost zero information in changelog for 2.067

On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:
> This code compile fine under both versions:
>
> dmd (2.066, -debug -d):

-d is your enemy, If you remove that, there will be a clear warning "Deprecation: variable XXX.S.FLAG_ON immutable field with initializer should be static, __gshared, or an enum". You decided to ignore and hide it, why the surprise about the breakage?

On Wednesday, 22 April 2015 at 11:36:35 UTC, Dicebot wrote:
> On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:
>> This code compile fine under both versions:
>>
>> dmd (2.066, -debug -d):
>
> -d is your enemy, If you remove that, there will be a clear warning "Deprecation: variable XXX.S.FLAG_ON immutable field with initializer should be static, __gshared, or an enum". You decided to ignore and hide it, why the surprise about the breakage?

The changelog entry comes from 2.065 : http://dlang.org/changelog.html#staticfields2

It would be probably good to repeat it in 2.067 now that new semantics have effect but the fault of ignoring deprecation messages before migration is 100% on user.

On Wednesday, 22 April 2015 at 11:36:35 UTC, Dicebot wrote:
> On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:
>> This code compile fine under both versions:
>>
>> dmd (2.066, -debug -d):
>
> -d is your enemy, If you remove that, there will be a clear warning "Deprecation: variable XXX.S.FLAG_ON immutable field with initializer should be static, __gshared, or an enum". You decided to ignore and hide it, why the surprise about the breakage?

I decided to ignore deprication messages, but I never expect it could lead to change semantics. I would expect compile breakage on 2.067 and after some releases maybe change of semantics. Btw. on 2.067 its compile even without -d parameter

On Wednesday, 22 April 2015 at 11:29:30 UTC, Daniel Kozak wrote:
> On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:
> static struct S
> {
>      immutable FLAG_ON = 1;
>      immutable FLAG_GPRS = 2;
>      immutable FLAG_HIDDEN = 4;
>      ubyte flags;
>      ubyte value;
>
>      bool isFlagSet(int flag)
>      {
>          return flags && flag == flag;
>      }
> }
>
> void main(string[ ] args)
> {
>      auto someData = [0x01, 0x10, 0x02, 0x16, 0x04, 0x08];
>      auto countS = someData.length / S.sizeof;
>
>      S[] sArray = (cast(S*)someData.ptr)[0 .. countS];
>      assert(sArray.length == 3);
> }

I agree that the change should be more prominent in the changelog.

Having said that, if your code makes an assumption about the layout (alignment and size) of a struct, it should `static assert` that assumption, or at least have a test case that relies it. You're just asking for trouble without that.

On Wednesday, 22 April 2015 at 11:41:53 UTC, Daniel Kozak wrote:
> On Wednesday, 22 April 2015 at 11:36:35 UTC, Dicebot wrote:
>> On Wednesday, 22 April 2015 at 11:28:44 UTC, Daniel Kozak wrote:
>>> This code compile fine under both versions:
>>>
>>> dmd (2.066, -debug -d):
>>
>> -d is your enemy, If you remove that, there will be a clear warning "Deprecation: variable XXX.S.FLAG_ON immutable field with initializer should be static, __gshared, or an enum". You decided to ignore and hide it, why the surprise about the breakage?
>
> I decided to ignore deprication messages, but I never expect it could lead to change semantics. I would expect compile breakage on 2.067 and after some releases maybe change of semantics. Btw. on 2.067 its compile even without -d parameter

It should have been an error in 2.066 according to plan published in 2.065
If it didn't happen, shifting the schedule for one release may be justified.

On Wednesday, April 22, 2015 11:28:43 Daniel Kozak via Digitalmars-d wrote:
> This code compile fine under both versions:
>
> dmd (2.066, -debug -d):
> OK
>
> dmd (2.067, -debug -d):
> core.exception.AssertError@main.d(24): Assertion failure
> ----------------
> ./main() [0x46413f]
> ./main(_Dmain+0x86) [0x449996]
> ./main(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f)
> [0x467d53]
> ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int
> function(char[][])*).tryExec(scope void delegate())+0x2a)
> [0x467ca6]
> ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int
> function(char[][])*).runAll()+0x30) [0x467d0c]
> ./main(void rt.dmain2._d_run_main(int, char**, extern (C) int
> function(char[][])*).tryExec(scope void delegate())+0x2a)
> [0x467ca6]
> ./main(_d_run_main+0x1dc) [0x467c20]
> ./main(main+0x17) [0x464157]
> /usr/lib/libc.so.6(__libc_start_main+0xf0) [0x7f4b8d440800]

What code does this? You just showed the output, not the code that triggers the problem.

- Jonathan M Davis