On Wednesday, 22 April 2015 at 14:13:01 UTC, Jonathan M Davis wrote:
> 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

http://forum.dlang.org/post/khhgviigmymiyitvnfkh@forum.dlang.org

You really should pay attention to the deprecation messages. immutable was unfortunately used as if it was a manifest constant before, but it ought to be a member of a struct, and that behaviour is changing. There's been a deprecation message there for a while, now the behaviour is changing, and eventually you'll be able to create immutable members of structs without any warnings, as it will just use the new behaviour.

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?

+100

On 4/22/15 7:41 AM, 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

You are misunderstanding what deprecation means then. The whole point is "the semantics are going to change, please update your code, it's coming soon". The -d is a way to get your code to compile now while you update.

-Steve

On 04/22/2015 01:36 PM, Dicebot wrote:
> 
> -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?

Maybe using -d should itself emit a warning?

On Thu, 23 Apr 2015 00:23:06 +0200, Martin Nowak wrote:

> On 04/22/2015 01:36 PM, Dicebot wrote:
>> 
>> -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?
> 
> Maybe using -d should itself emit a warning?

you can't protect people from themselves.

On 23 April 2015 at 00:23, Martin Nowak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 04/22/2015 01:36 PM, Dicebot wrote:
>>
>> -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?
>
> Maybe using -d should itself emit a warning?

People might start asking for a compiler switch to turn of -d emitting a warning...  :o)

On Wednesday, 22 April 2015 at 22:23:30 UTC, Martin Nowak wrote:
> On 04/22/2015 01:36 PM, Dicebot wrote:
>> 
>> -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?
>
> Maybe using -d should itself emit a warning?

This does not help (-d is not problem), you can not protect me from myself. Real problem is that changing semantics never end up well. If I skip 2.066(and many versions before) version of D compiler, I even do not get any deprecation or warning message. Original code is 2 years old (which should be legacy code for someone).

Even if this kind of change take more time, what time is enought?
2 years, 5 years, 10 years? What about old stackoverflow answers? IMHO it is impossible to make this right. We only can try to make it right as possible. And in this case I do not think we made it :(.

On Thursday, 23 April 2015 at 08:11:50 UTC, Daniel Kozak wrote:
> On Wednesday, 22 April 2015 at 22:23:30 UTC, Martin Nowak wrote:
>> On 04/22/2015 01:36 PM, Dicebot wrote:
>>> 
>>> -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?
>>
>> Maybe using -d should itself emit a warning?
>
> This does not help (-d is not problem), you can not protect me from myself. Real problem is that changing semantics never end up well. If I skip 2.066(and many versions before) version of D compiler, I even do not get any deprecation or warning message. Original code is 2 years old (which should be legacy code for someone).

Skipping compiler versions during upgrade is asking for trouble too. I don't remember it being done even for GCC - production users always do it one major version step at a time. And C was not supposed to change at all.

On Wednesday, 22 April 2015 at 16:10:37 UTC, Steven Schveighoffer wrote:
> You are misunderstanding what deprecation means then. The whole point is "the semantics are going to change, please update your code, it's coming soon". The -d is a way to get your code to compile now while you update.

So semantics can change just fine, a period of turning deprecation into an error is not needed at all?