DIP 1029---Add throw as Function Attribute---Community Review Round 1

[bachmeier]

On Tuesday, 14 January 2020 at 15:28:29 UTC, Joseph Rushton 
Wakeling wrote:
> On Tuesday, 14 January 2020 at 15:18:41 UTC, Arine wrote:
>> If you are going to add `throw` why aren't the rest of the 
>> attributes getting inverses? Pure? @nogc? etc...
>
> Because those changes are not contingent on one another.  One 
> can make this change without impacting any of the other 
> attributes.
>
> Where changes don't _need_ to be coupled, let's make the case 
> for each of them on their own merits.  It makes for a much 
> simpler change management process.

I disagree. That's how your language turns into C++. The tough 
part of language design is making decisions conditional on what 
the language as a whole looks like, and what it's going to be in 
ten years.

My opinion is that it's an ugly inconsistency to give only one 
attribute an inverse. Maybe others don't agree, but lately 
there's been an attempt to stifle discussion on major changes. 
That's fine, but then get rid of the DIP process, as it doesn't 
serve a purpose. Walter can push changes to master and then there 
can be announcement that the change has been made. No point 
pretending there's a process in place if you're not going to 
allow relevant discussion.

> (Or if you really think it's worthwhile in its own right, write 
> up your own DIP for a comprehensive set of invertible 
> attributes.)

This is a terrible idea. You don't need a DIP to counter a DIP. 
The DIP author has to write a document that can be defended. The 
ultimate goal is to make the right decision, not "best DIP wins".