Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
On 4/24/2015 12:22 AM, Martin Nowak wrote: On Friday, 24 April 2015 at 02:09:06 UTC, Walter Bright wrote: On 4/23/2015 6:26 AM, Steven Schveighoffer wrote: I agree it should have been done, not saying it's OK to break the process in some cases. I'm just explaining why it probably happened the way it did. Yes, it should have been done. We screwed up. It's time that we agree on/document an official deprecation approach and rigorously enforce it, making as few exceptions as possible. I thought we had one: 1. warning 2. deprecation 3. error 4. removal
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
On Saturday, 25 April 2015 at 06:37:28 UTC, Walter Bright wrote: I thought we had one: 1. warning 2. deprecation 3. error 4. removal Almost, but without warning stage. It caused lot of issues for no added value and most recent deprecations went through shorter cycle afair.
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
On 24 April 2015 at 09:22, Martin Nowak via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 24 April 2015 at 02:09:06 UTC, Walter Bright wrote: On 4/23/2015 6:26 AM, Steven Schveighoffer wrote: I agree it should have been done, not saying it's OK to break the process in some cases. I'm just explaining why it probably happened the way it did. Yes, it should have been done. We screwed up. It's time that we agree on/document an official deprecation approach and rigorously enforce it, making as few exceptions as possible. As it stands now, everyone follows their own policy. Any volunteer to put this in a DIP? One thing I noticed is that for many deprecations / planned deprecations, there is no issue in bugzilla (Override? .sort?) I hope you don't mind me doing the honours. https://issues.dlang.org/show_bug.cgi?id=14488 https://issues.dlang.org/show_bug.cgi?id=14489 https://issues.dlang.org/show_bug.cgi?id=14490 https://issues.dlang.org/show_bug.cgi?id=14491 https://issues.dlang.org/show_bug.cgi?id=14492 Regards Iain
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
On Friday, 24 April 2015 at 02:09:06 UTC, Walter Bright wrote: On 4/23/2015 6:26 AM, Steven Schveighoffer wrote: I agree it should have been done, not saying it's OK to break the process in some cases. I'm just explaining why it probably happened the way it did. Yes, it should have been done. We screwed up. It's time that we agree on/document an official deprecation approach and rigorously enforce it, making as few exceptions as possible. As it stands now, everyone follows their own policy. Any volunteer to put this in a DIP?
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
On 4/23/15 6:14 AM, Kagamin wrote: 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? Possibly this could have happened. Kind of too late now, though. But the reason it probably did not happen, is that for code that makes no assumptions about whether immutable fields affect struct layout or not, there is no danger. Only if you do dangerous stuff like casting raw bytes to a struct with immutable fields will you have problems. The OP code is dangerous with or without this change. As a general teaching moment, however, please don't ignore deprecation messages. They aren't just for laughs. And all is not lost! Just compile with 2.066 without -d switch and fix all your errors with initialized immutables. -Steve
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
We can make it an error in 2.067.1 and change semantics in 2.067 - actually I'd recommend to do it that way. Breaking normal deprecation process is not good.
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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.
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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)
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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 :(.
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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?
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
On 4/23/15 9:09 AM, Dicebot wrote: We can make it an error in 2.067.1 and change semantics in 2.067 - actually I'd recommend to do it that way. Breaking normal deprecation process is not good. I agree it should have been done, not saying it's OK to break the process in some cases. I'm just explaining why it probably happened the way it did. However, breaking it again in 2.067.1 is not good. Anyone who creates immutable fields for 2.067 and then upgrades to 2.067.1 is going to be upset. Even if we agree on how semantic changes should happen in the future (and should have happened in the past), it's not acceptable to change them for a point release. -Steve
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
On 4/23/2015 6:26 AM, Steven Schveighoffer wrote: On 4/23/15 9:09 AM, Dicebot wrote: We can make it an error in 2.067.1 and change semantics in 2.067 - actually I'd recommend to do it that way. Breaking normal deprecation process is not good. I agree it should have been done, not saying it's OK to break the process in some cases. I'm just explaining why it probably happened the way it did. Yes, it should have been done. We screwed up. However, breaking it again in 2.067.1 is not good. Anyone who creates immutable fields for 2.067 and then upgrades to 2.067.1 is going to be upset. Even if we agree on how semantic changes should happen in the future (and should have happened in the past), it's not acceptable to change them for a point release. Unfortunately, you're right.
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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/khhgviigmymiyitvn...@forum.dlang.org
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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.
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code 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? +100
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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?
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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. signature.asc Description: PGP signature
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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?
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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);
}
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
The worst thing is a runtime breakage and there is almost zero information in changelog for 2.067
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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?
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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.
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code 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? 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
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code 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.
Re: WTF: dmd 2.066 vs. dmd 2.067 really dangerous code breakage
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.
