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

[Joseph Rushton Wakeling]

On Tuesday, 14 January 2020 at 15:58:31 UTC, bachmeier wrote:
> 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.

I agree that one should think holistically when considering 
smaller changes.  But one should also be clear about what 
couplings really _need_ to exist, and which don't.

> My opinion is that it's an ugly inconsistency to give only one 
> attribute an inverse.

OK.  That's essentially an aesthetic concern, though: introducing 
an inverse for one attribute (where there is a particular 
motivation) doesn't block introducing other such inverses in 
future.  (Actually, it increases the likelihood of being able to 
do this, by proving the usefulness of invertible attributes.)

OTOH blocking this one motivated change with the argument that 
one must do this for all attributes or none, gets in the way of 
something useful.

BTW, as the DIP noted, the inconsistency already exists in the 
form of @safe and @system.

> Maybe others don't agree, but lately there's been an attempt to 
> stifle discussion on major changes.

Discuss away, as far as I'm concerned.  But if you want to push 
back on a small useful change on the grounds that it should be 
part of a much larger change, then it might be a good idea to 
bring stronger evidence of the _definite_ harm that will result 
from not taking the bigger-change route.

Too many folks have a tendency to say things like "It will turn D 
into C++!" when that is merely an opinion, not a demonstrable 
fact.  A lot of incompatible small feature steps can be 
problematic ... but that doesn't mean that a lot of small feature 
steps are a problem _in general_.

> 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.

Who's forbidding any discussion?  I simply offered an argument as 
to why this change should not be coupled with other changes to 
attributes, in response to an argument that it should be.  You 
have every right to articulate your disagreement -- just as I did.

> 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".

No, you don't need to write up a DIP to counter a DIP, but 
comprehensively introducing invertible attributes _will_ need a 
DIP.  So if you (or anyone else) thinks that is needed or 
valuable, it's worth putting that DIP together.

But if a DIP solves problem A, then it's not an argument against 
it to say, "But it doesn't solve B, C, D, ...".  It's necessary 
to show that solving A _without_ B, C, D, ... is actively harmful 
-- or that the particular solution to A is problematic in its own 
right.