I have a PR ready to test for issue 7616: aggregates don't inherit pure nothrow from outer scope. I would like some indication, before I spend a few hours testing it, whether a fix would be accepted.

https://issues.dlang.org/show_bug.cgi?id=7616

The current behavior:

pure nothrow @nogc:
int global;
struct Foo
{
  void foo() { global++; throw new Exception; }
}

Foo.foo is not pure, nothrow, or @nogc.

The spec does not specify any way in which pure, nothrow, or @nogc attribute propagation should differ from other attributes like @safe.

In this case, is the spec correct, or is the compiler correct? If the spec is correct, I'll finish my PR and submit it.

On 12/19/2018 3:29 PM, Neia Neutuladh wrote:
> I have a PR ready to test for issue 7616: aggregates don't inherit pure
> nothrow from outer scope. I would like some indication, before I spend a
> few hours testing it, whether a fix would be accepted.
> 
> https://issues.dlang.org/show_bug.cgi?id=7616
> 
> The current behavior:
> 
> pure nothrow @nogc:
> int global;
> struct Foo
> {
>    void foo() { global++; throw new Exception; }
> }
> 
> Foo.foo is not pure, nothrow, or @nogc.
> 
> The spec does not specify any way in which pure, nothrow, or @nogc
> attribute propagation should differ from other attributes like @safe.
> 
> In this case, is the spec correct, or is the compiler correct? If the spec
> is correct, I'll finish my PR and submit it.
> 

It's a good idea, but it will probably break a lot of code :-(

On Wed, 19 Dec 2018 17:19:23 -0800, Walter Bright wrote:
> It's a good idea, but it will probably break a lot of code :-(

Yes. Does that mean a transition flag and a deprecation period, or submit a DIP and see how it goes, or it's going to be rejected no matter what?

On 12/19/2018 5:48 PM, Neia Neutuladh wrote:
> On Wed, 19 Dec 2018 17:19:23 -0800, Walter Bright wrote:
>> It's a good idea, but it will probably break a lot of code :-(
> 
> Yes. Does that mean a transition flag and a deprecation period, or submit
> a DIP and see how it goes, or it's going to be rejected no matter what?
> 

There was a good reason it is the way it is, but I don't recall just what it was. Sigh.

On Wed, 19 Dec 2018 21:02:20 -0800, Walter Bright wrote:
> There was a good reason it is the way it is, but I don't recall just what it was. Sigh.

After spelunking through git (thanks git log -L!), I found out how the source code came to look like it does:

https://issues.dlang.org/show_bug.cgi?id=5110

The 'override' keyword propagated to functions defined inside nested classes:

class Foo
{
  override:
  string toString() { return ""; }
  class Bar
  {
    // error: doStuff doesn't override any function
    void doStuff() {}
  }
}

Some amount of filtering was strongly suggested. (The spec was not updated with this change.)

Shin Fujishiro thought it was awkward for pure and nothrow to propagate to structs because there was no way to turn them off. Because of that, they chose to filter out pure and nothrow. This allowed you to be more flexible withh aggregates, but it did nothing for free functions; you still commonly need to reorder declarations or use `pure {}` or set the attributes on each item individually.

So there *was* a reason; whether it's a good one or not is a matter of opinion.

Does this mean a DIP is required?

On 12/19/2018 9:49 PM, Neia Neutuladh wrote:
> Does this mean a DIP is required?


Thanks for doing the work. I suspected that was the reason. Yes, it would require a DIP. But I doubt it would be accepted, because of breakage.