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
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.
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
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
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
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.
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
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,
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
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
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
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
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
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
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,
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
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?
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
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)
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]
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;
}
}
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)
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,
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
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
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
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
28 matches
Mail list logo
