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

> 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

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.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to