[dmd-internals] Implementation change without matching spec change

[Walter Bright via dmd-internals]

Of course you have a great point. The trouble is, for me anyway, it's hard to 
write the spec incrementally. It also tends to make for a crummy spec. I find it 
easier and works better to take a more holistic view of spec updates.

For example, I am currently working on the list of issues tagged with 'safe'. 
Many of them interact with each other. It's easier to work on them more or less 
in parallel when I have the 'context' of how that part of the code works in my 
head. The same goes for spec updates.

But I don't want it overlooked, hence the shortcomings should all have bugzilla 
entries.

On 6/27/2016 2:06 AM, Михаил Страшун via dmd-internals wrote:
> On 06/24/2016 09:14 AM, Walter Bright via dmd-internals wrote:
>> All such issues should be files as bugzilla entries and marked with the
>> 'spec' keyword.
>
> This is fighting consequence and not a problem. Better approach would be
> to have a simple checklist for all dmd/phobos mergers to follow:
>
> - Does this PR have tests?
> - Does this PR have documentation?
> - Does language spec and/or dlang.org articles need to be updated? If
> yes, is there a PR for that?
> - Does ths PR need changelog entry? If yes, is it there?
>
> If there is a failure on any of these points, PR must not be merged, no
> exceptions or excused. Not even if it is written by you and desperately
> needed by Andrei - for a simple reason that being too slow will never do
> as much damage to the language as making bad quality changes.