On Saturday, 3 June 2017 at 06:09:21 UTC, Jonathan M Davis wrote:
> On Saturday, June 03, 2017 02:00:13 Jack Stouffer via Digitalmars-d-announce wrote:
>> I recommend a longer deprecation cycle than usual for this, as this will break many legacy libraries that don't get maintained often. A period of two years sounds about right.
>
> For Phobos, that _is_ the normal length of the deprecation cycle. For the language itself, I don't think that it's anywhere near as consistent, but I've gotten the impression that deprecations in the language usually stick around for quite awhile, but I haven't exactly tracked it closely, so I don't know.
>
> - Jonathan M Davis

All of the recent Phobos deprecations have been a year. 18 months at most.

On Sunday, June 04, 2017 05:56:15 Jack Stouffer via Digitalmars-d-announce wrote:
> On Saturday, 3 June 2017 at 06:09:21 UTC, Jonathan M Davis wrote:
> > On Saturday, June 03, 2017 02:00:13 Jack Stouffer via
> >
> > Digitalmars-d-announce wrote:
> >> I recommend a longer deprecation cycle than usual for this, as this will break many legacy libraries that don't get maintained often. A period of two years sounds about right.
> >
> > For Phobos, that _is_ the normal length of the deprecation cycle. For the language itself, I don't think that it's anywhere near as consistent, but I've gotten the impression that deprecations in the language usually stick around for quite awhile, but I haven't exactly tracked it closely, so I don't know.
> >
> > - Jonathan M Davis
>
> All of the recent Phobos deprecations have been a year. 18 months at most.

If you think that, I think that you misunderstand how the Phobos deprecation process works. When a symbol is deprecated, it's marked in the documentation with the year-month that it will be removed from the documentation (usually about one year from the point that it's deprecated). Once that year has passed, the documentation is removed from Phobos, and instead, it's marked with a non-ddoc comment stating that the symbol is explicitly undocumented and that it will be removed at year-month where that's usually a year from when the symbol is removed from the documentation. Once that second date arrives, the symbol is completely removed. So, the whole deprecation cycle is approximately two years, and if anything, it sometimes takes a bit longer, because I'm sometimes slow to move the symbol along to the next stage.

I suspect that what's confused you is that when the symbol is deprecated, it states in the documentation that the symbol will be removed at year-month and does not say anything about the fact that that removal date is when it will be removed from the documentation, not when it will be fully removed from the library.

- Jonathan M Davis

On 2017-06-04 01:10, Jonathan M Davis via Digitalmars-d-announce wrote:

> Only new Phobos modules. DIPs have been discussed quite a bit in the
> newsgroup, but their decision process has never been democratic. It's always
> been a matter of talking Walter into it, which has usually led to stuff
> never going anywhere when we haven't had a process for it with someone
> organizing it. Previously, I think that most DIPs that got implemented were
> something that Walter was personally interested in, or you managed to
> convince him in person. What Dicebot and Mike have done with DIPs has
> changed things drastically, but it's still completely up to Walter and
> Andrei.

Right.

-- 
/Jacob Carlborg

On Sunday, 4 June 2017 at 03:01:41 UTC, Walter Bright wrote:
> On 6/3/2017 5:20 PM, Mike Parker wrote:
>> There's currently a proposal in the PR queue to enhance the contract syntax.
>> 
>> https://github.com/dlang/DIPs/pull/66
>
> I know. That's as it should be!

Well that's encouraging! Thanks!

On Saturday, 3 June 2017 at 20:06:05 UTC, Walter Bright wrote:
> On 6/3/2017 12:28 AM, Petar Kirov [ZombineDev] wrote:
>> Personally, making contracts less verbose and more powerful is much higher on my list
> We did discuss bouncing the DIP back with a request to revamp it as a complete overhaul of the contract syntax, but decided that this DIP was about resolving a simple and immediate problem, and it shouldn't be held up on that basis.

Yes, keeping scope of DIP1003 was the right call. In order to for the process to be effective, we need to have good turnaround time.
That said, I'm glad to hear that the idea of an overhaul the contract syntax is on your radar. Related to that, is the need to formally specify what exactly is the compiler allowed to assume via asserts. Currently the answer is offensive​ programming [0] which doesn't play well with domains that require defensive​ programming. But that's a topic for another day and another DIP.

[0]: https://en.wikipedia.org/wiki/Defensive_programming#Offensive_programming

On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

The "See the previous version" link at the end of the document is currently broken and leads to a 404.

Thank you for your efforts and congratulations to Jared Hanson!

On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote:
> Congratulations are in order for Jared Hanson. Walter and Andrei have approved his proposal to remove body as a keyword. I've added a summary of their decision to the end of the DIP for anyone who cares to read it. In short:
>
> * body temporarily becomes a contextual keyword and is deprecated
> * do is immediately allowed in its place
> * body is removed and do replaces it fully
>
> Congratulations, Jared!
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md

Well, guess I'm a bit late to the party but I just wanted to echo the sentiment that Mike has done a great job stepping up to oversee the DIP process. All I had to do was write it, and he did the rest. I'm very pleased with how smoothly things went and how easy Mike made the whole process. Thanks Mike!