www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.internals - Issue 7616: intentional or fix welcome?

reply Neia Neutuladh <neia ikeran.org> writes:
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.
Dec 19 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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 :-(
Dec 19 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
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?
Dec 19 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 19 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
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?
Dec 19 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 20 2018