This week I had a tele-meeting with Andrei and Walter regarding the fate
of DIP1000 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)
and intented way to move forward with it. This is a short summary of the
meeting.

Approval of DIP1000
-------------------

DIP1000 is going to be approved as the basis of the idea
but exact specification may change during implementation and as a result
of incorporating some ideas from feedback threads
(http://forum.dlang.org/thread/pqsiqmkxenrwxoruzaml@forum.dlang.org and
http://forum.dlang.org/thread/rwxcfapvpfiqmfsuixlf@forum.dlang.org).

Core principles that are sure to stay at this point:
- scope is a storage class
- scope is non-transitive
- scope is @safe only
- responsibility of implementing complicated scope-using types is on
developer, compiler magic is intended to be minimal

Any changes in intended DIP1000 spec will be reflected in original
document (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md).

Implementation of DIP1000
-------------------------

Walter is currently working on implementing the support via
https://github.com/dlang/dmd/pull/5972, which will take some time. Once
it is more feature complete I'll contact Martin for possible
out-of-release preview compiler builds from that branch to try it out
easily. About that time we will start another feedback thread in the NG
with a more practical focus - featuring more code examples and design
idioms.

Life after DIP1000
------------------

It is acknowledged that DIP1000 itself does not allow to implemented
completely @safe reference counting, primarily because of an issue with
@trusted destructor and re-assignment. Intention is to follow up with
another proposal (not directly related) to address the issue from
another angle - but this will only become in focus after DIP1000 is
finished.

On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:
> - scope is @safe only

Why? I might have @system code that could still benefit from scope.

On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote:
> On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:
>> - scope is @safe only
>
> Why? I might have @system code that could still benefit from scope.

I guess it would be too restrictive, but I'm just a bit frustrated at having to choose between lots of compiler checking and none at all. I wish there was a flag for the compiler that would give @safe violations as warnings in @system / @trusted code, it would be too noisy for routine use but it would be great to occasionally look through.

On Sunday, August 21, 2016 21:52:59 John Colvin via Digitalmars-d-announce wrote:
> On Sunday, 21 August 2016 at 21:46:56 UTC, John Colvin wrote:
> > On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:
> >> - scope is @safe only
> >
> > Why? I might have @system code that could still benefit from scope.
>
> I guess it would be too restrictive, but I'm just a bit frustrated at having to choose between lots of compiler checking and none at all. I wish there was a flag for the compiler that would give @safe violations as warnings in @system / @trusted code, it would be too noisy for routine use but it would be great to occasionally look through.

Well, if you typically try and restrict your @system code to small parts of your program and use @trusted to turn them into @safe, then the vast majority of your program will be @safe. As I understand it, that's at least how it was _intended_ that @system be dealt with - though plenty of folks just don't bother with @safe, and it's certainly the case that code out there doesn't restrict the @system portions as much as it could.

So, at least _in theory_, if you're using @safe as intended, even if you have a fair number of code snippets which are @system, you can take advantage of stuff like scope in most of your code. I don't know how well that will work in practice though.

I can think of two big reasons to restrict something like this to @safe code though. One is that implementing something like this usually means declaring some stuff illegal that is actually safe, because the compiler can't be perfect about it (a similar example would be how a lot of lambdas end up allocating closures in order to be @safe when they don't actually need to; the compiler simply isn't smart enough to figure out that it isn't necessary and may or may not be able to with what the language allows the programmer to do). Another reason is that sometimes in order to make certain guarantees, the compiler has to be able to assume things that aren't necessarily true in @system code, even if they happen to be true for most @system code.

- Jonathan M Davis

On 8/21/2016 7:01 PM, Jonathan M Davis via Digitalmars-d-announce wrote:
> Well, if you typically try and restrict your @system code to small parts of
> your program and use @trusted to turn them into @safe, then the vast
> majority of your program will be @safe. As I understand it, that's at least
> how it was _intended_ that @system be dealt with - though plenty of folks
> just don't bother with @safe, and it's certainly the case that code out
> there doesn't restrict the @system portions as much as it could.
>
> So, at least _in theory_, if you're using @safe as intended, even if you
> have a fair number of code snippets which are @system, you can take
> advantage of stuff like scope in most of your code. I don't know how well
> that will work in practice though.
>
> I can think of two big reasons to restrict something like this to @safe code
> though. One is that implementing something like this usually means declaring
> some stuff illegal that is actually safe, because the compiler can't be
> perfect about it (a similar example would be how a lot of lambdas end up
> allocating closures in order to be @safe when they don't actually need to;
> the compiler simply isn't smart enough to figure out that it isn't necessary
> and may or may not be able to with what the language allows the programmer
> to do). Another reason is that sometimes in order to make certain
> guarantees, the compiler has to be able to assume things that aren't
> necessarily true in @system code, even if they happen to be true for most
> @system code.

I agree. If there's a lot of @system code in a program, something has gone awry in its design. I understand the desire to be able to turn each individual safety feature on and off, but don't think the code really will be better off that way.

On 2016-08-21 22:01, Dicebot wrote:
> This week I had a tele-meeting with Andrei and Walter regarding the fate
> of DIP1000 (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)
> and intented way to move forward with it. This is a short summary of the
> meeting.
>
> Approval of DIP1000
> -------------------
>
> DIP1000 is going to be approved as the basis of the idea
> but exact specification may change during implementation and as a result
> of incorporating some ideas from feedback threads
> (http://forum.dlang.org/thread/pqsiqmkxenrwxoruzaml@forum.dlang.org and
> http://forum.dlang.org/thread/rwxcfapvpfiqmfsuixlf@forum.dlang.org).
>
> Core principles that are sure to stay at this point:
> - scope is a storage class
> - scope is non-transitive
> - scope is @safe only
> - responsibility of implementing complicated scope-using types is on
> developer, compiler magic is intended to be minimal
>
> Any changes in intended DIP1000 spec will be reflected in original
> document (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md).
>
> Implementation of DIP1000
> -------------------------
>
> Walter is currently working on implementing the support via
> https://github.com/dlang/dmd/pull/5972, which will take some time. Once
> it is more feature complete I'll contact Martin for possible
> out-of-release preview compiler builds from that branch to try it out
> easily. About that time we will start another feedback thread in the NG
> with a more practical focus - featuring more code examples and design
> idioms.
>
> Life after DIP1000
> ------------------
>
> It is acknowledged that DIP1000 itself does not allow to implemented
> completely @safe reference counting, primarily because of an issue with
> @trusted destructor and re-assignment. Intention is to follow up with
> another proposal (not directly related) to address the issue from
> another angle - but this will only become in focus after DIP1000 is
> finished.

It would be nice to have the whole picture now, before implementing DIP1000. Then it's possible to review them together, making sure the end goal is actual possible to achieve. Now we just have to trust Andrei and Walter that all features will come together making the end goal possible. We've already seen in the past that some features don't play well together.

It's also not possible/harder to come up with alternatives, that might work better, if we don't have the whole picture.

I'm also not a big fan that the DIP is approved right from the start. Then it's not a DIP, it's more of a FYI. It makes the whole process kind of pointless since Andrei and Walter can choose to ignore the feedback.

-- 
/Jacob Carlborg

On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote:
> It would be nice to have the whole picture now, before implementing DIP1000. Then it's possible to review them together, making sure the end goal is actual possible to achieve. Now we just have to trust Andrei and Walter that all features will come together making the end goal possible. We've already seen in the past that some features don't play well together.
>
> It's also not possible/harder to come up with alternatives, that might work better, if we don't have the whole picture.
>
> I'm also not a big fan that the DIP is approved right from the start. Then it's not a DIP, it's more of a FYI. It makes the whole process kind of pointless since Andrei and Walter can choose to ignore the feedback.

What he said !

On Monday, 22 August 2016 at 06:44:11 UTC, Jacob Carlborg wrote:
> It would be nice to have the whole picture now, before implementing DIP1000.

It can be reviewed after the spec is inferred from implementation. But yes, it can be unclear how the implementation can affect the review process.
Do you have an alternative design for scope?

On 08/22/2016 12:46 AM, John Colvin wrote:
> On Sunday, 21 August 2016 at 20:01:27 UTC, Dicebot wrote:
>> - scope is @safe only
> 
> Why? I might have @system code that could still benefit from scope.

Because it can't provide expected guarantees within feature set allowed by @system - it is too permissive for such simple system. Probably actual scope semantics will remain in @system but it won't guarantee anything.

On 08/22/2016 09:44 AM, Jacob Carlborg wrote:
> It would be nice to have the whole picture now, before implementing DIP1000. Then it's possible to review them together, making sure the end goal is actual possible to achieve. Now we just have to trust Andrei and Walter that all features will come together making the end goal possible. We've already seen in the past that some features don't play well together.

My understanding is that those are not supposed to be related in any direct way and danger of @trusted destructor is inherent to DIP1000 design (it should be better clarified in document itself though, see https://github.com/dlang/DIPs/pull/35)

> I'm also not a big fan that the DIP is approved right from the start. Then it's not a DIP, it's more of a FYI. It makes the whole process kind of pointless since Andrei and Walter can choose to ignore the feedback.

By its design definition DIP process is for approving communitty proposals by Walter/Andrei thus there is no point in pretending they can't ignore the feedback. Only reason it is even processed in the same queue is so that developers can track all major proposed changes in one place.

I would personally prefer to see more of a commitee approach for validating such changes but that concept is far beyond available resources and community engagement. If both language authors agree that certain issue is urgent to solve than, in absence of formally written counter-proposals, there is no other way but to move ahead.

Again, the DIP process is not for Walter or Andrei - it is for everyone else wanting to get their attention and submit good quality technical proposal. I hope authors of already submitted DIPs will improve them to required content bar and we will see how the process actually work but that is still to come.

Note that during the meeting I did go through the list of all comments submitted through the community feedback to ensure that nothing was simply missed or forgotten and every issue is acknowledged. But all the decision making is 100% for Andrei/Walter in the end and I don't see how it can be different with existing state of affairs.