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

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

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.

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?

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

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

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.