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.

This would be a step forward, of course. But would not it be better to kill the one-way attribute problem in one go -meaning, making an antiattribute for `pure` and `@nogc` too?

In addition, I suggest that there should be a way to use [`pure:`/`nothrow:`/`@nogc:`/`@safe:`/their antiattributes] so that they only apply when attributes are not inferred - not for templated functions. This would also remove a big obstacle from front of DIP1028, as one could just mark the whole module `@system` with one statement without killing template `@safe` or `@live` inference.

Also a few smaller things:

-Why `throw` instead of `@throw`? I'm not saying it's a bad idea, but write the rationale in DIP.

-You mention that due to lack of an antiattribute, aggregates don't propagate @nothrow to their member function. Since you claimed "no breaking changes", I guess you meant it to be left that way. But the DIP should be explicit about that.

On Tuesday, 14 January 2020 at 16:32:51 UTC, Joseph Rushton Wakeling wrote:
> 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:

Is it a big deal? Maybe not, but it's strange to say "You can invert [random attribute] but no others." "Oh, why is that?" "Because that's all that was in the DIP." It's just sloppy and amateurish to design a language like that.

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

I don't even know if that's a good idea. All I'm asking for is a sensible argument in favor of adding an inverse of one and only one attribute. It makes absolutely no sense to me to have negation of nothrow but not nogc.

On Tuesday, 14 January 2020 at 17:01:42 UTC, bachmeier wrote:
>
> I don't even know if that's a good idea. All I'm asking for is a sensible argument in favor of adding an inverse of one and only one attribute. It makes absolutely no sense to me to have negation of nothrow but not nogc.

I'm guessing that the reason is that one goal of this DIP was that it shouldn't have any breaking changes. However, if there is a future DIP for having "nothrow" as default, then it actually matters more.

On Tuesday, 14 January 2020 at 17:01:42 UTC, bachmeier wrote:
> Is it a big deal? Maybe not, but it's strange to say "You can invert [random attribute] but no others." "Oh, why is that?" "Because that's all that was in the DIP." It's just sloppy and amateurish to design a language like that.

Yes, but that's not the answer, is it?  The answer to "Why is that?" is, possibly among other things, "Because it enables a transition path to exceptions being opt-in rather than opt-out."

(Note there is no reason in principle why `nothrow` might not get deprecated and dropped if such a transition actually happens, so long run we may not end up with the one invertible attribute.)

However, that does raise a good piece of review feedback: is it appropriate to introduce this new attribute as a DIP in its own right, rather than as a migration path for the nothrow-by-default DIP?  Are there use-cases other than the transition that motivate the `throw` attribute or make it valuable?

It would be good if the DIP could articulate those arguments if they exist -- and if they do not, perhaps its acceptance should be made conditional on the (not yet finalized) nothrow-by-default DIP.

>> 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.
>
> I don't even know if that's a good idea. All I'm asking for is a sensible argument in favor of adding an inverse of one and only one attribute. It makes absolutely no sense to me to have negation of nothrow but not nogc.

You could look at that from the opposite point of view: what's the point in introducing an inverse to a particular attribute unless it has a practical motivation beyond the concept that "attributes should be invertible"?

FWIW I do think it would be helpful for the DIP to offer a response to your question.

On Tuesday, 14 January 2020 at 16:32:51 UTC, Joseph Rushton Wakeling wrote:
> 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.

It's not even solving a problem. That's the problem. This DIP is just a change that should be included in the DIP that plans to make nothrow default. Then it solves a problem for *that* DIP. *This* DIP doesn't illustrate a problem, and as such can't be a solution to a problem that doesn't exist (in this DIP). If the problem is that attributes don't have inverses, then this isn't a sufficient enough solution to that problem.

On Tuesday, 14 January 2020 at 17:24:04 UTC, Arine wrote:
> It's not even solving a problem. That's the problem. This DIP is just a change that should be included in the DIP that plans to make nothrow default. Then it solves a problem for *that* DIP.

I agree that it should be clarified if this is the case (see my post above).

On 1/14/2020 3:21 AM, WebFreak001 wrote:
> I don't think making the attribute "throw" is the best way to go though. Currently most attributes use the at-attribute syntax which makes them very unambiguous and easier to (visually) parse. I would suggest instead of having throw as attribute, the new attribute should be @throws instead. `throws` can also be argued for that it is "better" to read like: "function foo throws" than "function foo throw"

It's already a keyword so there's no problem with having it be 'throw'.

Having 'throw', 'nothrow' and 'throws' as keywords looks excessive.


> Additionally if we make this an at-attribute, it can very easily be extended in the future to have arguments what kind of exceptions are being thrown by this function, for example using template argument syntax to be the easiest and most consistent to parse. This also exists in other languages like Java and helps both with linting for try-catch, but also extremely helps with documentation.
> 
> For symmetry with nothrow it might be worth looking into providing nothrow as @nothrow attribute instead too.

The @ syntax for this is simply unnecessary.

On 1/14/2020 7:18 AM, Arine wrote:
> Why isn't this being fixed so that `nothrow{}` then applies to `S2.foo()`? Why is it even part of the rationale if there's no intention to fix this?

Because it's the way the other attributes work. Trying to change this would be very disruptive. The reason it works this way is it is unkind to the purpose of scoping. If the attributes passed into nested scopes, then you'll pretty much force a coding guideline to "list all the attributes needed at the beginning of each scope" so it won't silently break when someone adds a:

 attribute:

at the top.


> If you are going to add `throw` why aren't the rest of the attributes getting inverses? Pure? @nogc? etc...

Since we already have a keyword available, it makes sense to use it. throw/nothrow nicely complement each other.


> Just adding `throw` isn't a significant/meaningful enough change on it's own, if you look solely at this DIP.

It does add value on its own, as the user can now decide what his default is and override it as necessary. The value isn't huge, but the change is trivial, so the cost/benefit ratio is still good.

On 1/14/2020 7:18 AM, Arine wrote:
> Otherwise this shouldn't be it's own DIP. If the intention is this is only required for another DIP, this should just be included in that DIP.
It does make sense on its own.

Furthermore, I don't want to distract the coming discussion on "nothrow as default" with all the debate about throw vs throws vs @throw, etc.

BTW, anyone wanting to discuss the merits of "nothrow as default" please use the "nothrow by default" thread started by Steven Schveighoffer on Jan 4.