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/pqsiqmkxenrwxoruz...@forum.dlang.org and
http://forum.dlang.org/thread/rwxcfapvpfiqmfsui...@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

Reply via email to