On 12/07/2016 05:34 AM, Walter Bright wrote:
> On 12/6/2016 5:54 PM, Dicebot wrote:
>> On 12/05/2016 03:10 AM, Walter Bright wrote:
>>> The table makes sense and looks right. But there's a problem with the return scope changes. It's just too much to just wholesale deprecate things all at once.
>>
>> It will need to happen at some point anyway. Without having those deprecation implemented we can't even know how much existing code is affected.
> 
> That's the point of the flag. It can be done on the user's timescale, not ours.

Flags don't allow for user timescale, only deprecations do. Flag can be one of possible preview options but you can't start adjusting your projects while it is in flag mode because that will break all downstream projects that depend on yours (and don't want to enable the flag yet).

>>> People need time to ease into it, not be faced with
>>> a pile of diverse deprecation messages.
>>
>> We can introduce `-preview=XXX` flag for that purpose but the key thing is that it still has to use deprecations and not errors for all scope related changes. Otherwise you introduce dangerous disparity between what gets previewed and what will eventually become the default.
> 
> I agree, but it doesn't have to be deprecations until the flag becomes the default.

Practice has shown that if it isn't deprecation from the very start, you won't change it later and it will be me or Martin adjusting it in hurry mode before release. I don't want that. For you as original implementor there should be no difference in effort required between implementing checks as deprecations or errors - as such, I can't find any excuse to not do it from the very beginning.

>> 2) You must not use the very same flag for bug fixes as an excuse to not bother of deprecations. https://github.com/dlang/dmd/pull/6290 is the last one remaining now there was no justification to merge it in first place.
> 
> There isn't a hard line between what is a bug and what is not. It'd be nice if there was. Pretty much all of these fall under fixing unsafe code.

It is irrelevant, you have misread the statement. Breaking change requires deprecations, no matter if it is a bug fix or not. You can add additional helpful information via -transition flag but it still has to be deprecation and using any kind of flag can't be an excuse to not do so.

On 12/07/2016 06:39 AM, Walter Bright wrote:
> On 12/6/2016 6:03 PM, Dicebot wrote:
>> On a more serious note - not breaking things is much more important than fixing things. Even if existing issue is severe, the fact that it exists for a long time means users have a way to mitigate it. You can't make things worse by delaying it for one release. One the other hand, any issue that causes existing projects to break has sever consequence for ecosystem usability.
> 
> On the other hand, we cannot progress the language by freezing it. After all, one transitions to newer versions of the language for good reason. Furthermore, bugs (especially safety problems) can be a silent liability for any code that has them.
> 
> So, yes, delaying these sorts of fixes can most definitely make things worse for users.

We will get much better progress by slowing it down and improving stability. It will be slower, but consistent. Right now D development happens in a "1 step forward, 0.5 to 2 steps back" mode. Last two releases were terrible.

Again - you can't do harm by reverting a problematic change. If problem was not dire enough to make previous release unusable, it can always wait for one release more. We can't scale to more contributors if working with master branch requires knowledge of all half-broken changes that were not reverted.

> This is why I push hard on these safety fixes. I want them fixed before they suddenly cost somebody on code they thought was fine.

And that is why I oppose so hard to your way of doing things. By attempt to fix bugs we don't care about you are willing to straight up fuck our working code that we do care about. It doesn't matter how much you make things better if you also make things worse.

>> I am perfectly fine with "any rule must have exceptions approach". But there has to be at least some basic rule. Productivity of D development suffers from decision reluctance horribly exactly because there is no way to say if something non-trivial is OK to merge unless you come and say so.
> 
> I've approved a lot of PRs that turned out to cause regressions. I don't know of any way to prove that PRs do not introduce regressions. At least we have a test suite that gets continuously added to - that helps enormously.

Well here is PR which does introduce regression. It exists in master for months. It blocks further progress with syncing scope branch and master. And yet you oppose reverting it. What is the point? You complain about slow progress with dip1000 but your are also the main person putting obstacles to move forward with it.

On 12/10/2016 09:40 AM, Martin Nowak wrote:
> On Wednesday, 7 December 2016 at 01:54:18 UTC, Dicebot wrote:
>> Otherwise you introduce dangerous disparity
> 
> Please refrain from using exaggerating adjectives, they don't make your arguments better.

There is no exaggeration here. I have said what I believe and mean, quite literally. For feature branch to work you need to be able to merge it into master with no changes once ready. Any tiny step sidewards from that condition compromises master branch quality in a same way as merging PR with broken tests and trying to fixup it later.

On Monday, 12 December 2016 at 01:05:20 UTC, Walter Bright wrote:
> On 12/10/2016 6:14 AM, Mathias Lang via Dlang-internal wrote:
>> Since scope class are not testable, I wouldn't say it's finished.
>
> Please be more specific.

- Due to a regression, we cannot have `scope`-allocated classes in `@safe` code (https://github.com/dlang/dmd/pull/6279).
- By design, `scope` rules are not enforced outside of `@safe` code

Ergo, one part of the feature (classes, a fairly important one) cannot be tested.

On 12/11/2016 11:15 PM, Mathias Lang wrote:
> On Monday, 12 December 2016 at 01:05:20 UTC, Walter Bright wrote:
>> On 12/10/2016 6:14 AM, Mathias Lang via Dlang-internal wrote:
>>> Since scope class are not testable, I wouldn't say it's finished.
>>
>> Please be more specific.
>
> - Due to a regression, we cannot have `scope`-allocated classes in `@safe` code
> (https://github.com/dlang/dmd/pull/6279).

That's both testable, and has been fixed.

> - By design, `scope` rules are not enforced outside of `@safe` code

Yes - many checks are not done outside of @safe code.

> Ergo, one part of the feature (classes, a fairly important one) cannot be tested.

Since it's by design, I don't see why that makes it unfinished.

On Monday, 12 December 2016 at 08:01:19 UTC, Walter Bright wrote:
> On 12/11/2016 11:15 PM, Mathias Lang wrote:
>> On Monday, 12 December 2016 at 01:05:20 UTC, Walter Bright wrote:
>>> On 12/10/2016 6:14 AM, Mathias Lang via Dlang-internal wrote:
>>>> Since scope class are not testable, I wouldn't say it's finished.
>>>
>>> Please be more specific.
>>
>> - Due to a regression, we cannot have `scope`-allocated classes in `@safe` code
>> (https://github.com/dlang/dmd/pull/6279).
>
> That's both testable, and has been fixed.
>
>> - By design, `scope` rules are not enforced outside of `@safe` code
>
> Yes - many checks are not done outside of @safe code.
>
>> Ergo, one part of the feature (classes, a fairly important one) cannot be tested.
>
> Since it's by design, I don't see why that makes it unfinished.

Let's move this discussion to the DIP1000-related thread: https://forum.dlang.org/post/iphydbpprkuceqprkxhb@forum.dlang.org