On the future of DIP1000

[Jacob Carlborg via Digitalmars-d-announce]

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