• Neia Neutuladh (11/11) Dec 16 2018 When the spec says that one thing should happen and the compiler does
• rikki cattermole (1/1) Dec 16 2018 If it doesn't match bug report.
• Stanislav Blinov (8/9) Dec 16 2018 And then what? Example:
• Neia Neutuladh (5/6) Dec 16 2018 The bug report is six years old and has not had an official response. I
• rikki cattermole (3/10) Dec 16 2018 You did the right thing making noise about it, though a link to the
• Neia Neutuladh (3/5) Dec 16 2018 Thank you.
• Stanislav Blinov (3/8) Dec 16 2018 All of the above in unspecified order, sometimes fruitlessly,
• Steven Schveighoffer (14/28) Dec 16 2018 Making rules about such things would necessitate accepting bad decisions...
• Neia Neutuladh (8/17) Dec 16 2018 Your options:
• Steven Schveighoffer (11/37) Dec 16 2018 None of those are good options.
• Adam D. Ruppe (14/16) Dec 16 2018 If the spec says it and the code is not compliant, the code is
• Neia Neutuladh (7/13) Dec 16 2018 I mean, yes, they're not super awesome. But it's also not like this is
• Stanislav Blinov (4/7) Dec 16 2018 On that topic specifically, I say no, @nogc shouldn't propagate.

Neia Neutuladh <neia ikeran.org> writes:

When the spec says that one thing should happen and the compiler does 
something different, should we generally take the spec to be correct, or 
should we take the compiler to be correct? Do we need to ask Walter every 
time, or go spelunking through github comments and the newsgroup to figure 
it out?

When we want to change the compiler to be in line with the spec, does that 
require a DIP? When we want to change the spec to be in line with the 
compiler, does that require a DIP?

The specific question here is whether attributes like  nogc should 
propagate into nested declarations the same as  trusted (as the spec says) 
or not (as the compiler implements).

rikki cattermole <rikki cattermole.co.nz> writes:

If it doesn't match bug report.

Stanislav Blinov <stanislav.blinov gmail.com> writes:

On Sunday, 16 December 2018 at 18:20:29 UTC, rikki cattermole 
wrote:
 If it doesn't match bug report.

And then what? Example: 
https://issues.dlang.org/show_bug.cgi?id=19348

I'm really hoping that's just a spec bug, because the behavior is 
useful. But with no response I'm not wasting time on a PR. I 
guess it's just too new, it's "only" 1.5 months old, that's not 
even a newborn issue as far as D's bugzilla goes :)

Neia Neutuladh <neia ikeran.org> writes:

On Mon, 17 Dec 2018 07:20:29 +1300, rikki cattermole wrote:
 If it doesn't match bug report.

The bug report is six years old and has not had an official response. I 
submitted a PR and one of the reviewers recommended that I search the 
newsgroup and github PR comments and the like to see if Walter had said 
anything on the topic.

rikki cattermole <rikki cattermole.co.nz> writes:

On 17/12/2018 8:39 AM, Neia Neutuladh wrote:
 On Mon, 17 Dec 2018 07:20:29 +1300, rikki cattermole wrote:
 If it doesn't match bug report.

 
 The bug report is six years old and has not had an official response. I
 submitted a PR and one of the reviewers recommended that I search the
 newsgroup and github PR comments and the like to see if Walter had said
 anything on the topic.

You did the right thing making noise about it, though a link to the 
issue would have been better  :)

Neia Neutuladh <neia ikeran.org> writes:

On Mon, 17 Dec 2018 13:45:51 +1300, rikki cattermole wrote:
 You did the right thing making noise about it, though a link to the
 issue would have been better  :)

Thank you.

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

Stanislav Blinov <stanislav.blinov gmail.com> writes:

On Sunday, 16 December 2018 at 18:16:58 UTC, Neia Neutuladh wrote:
 When the spec says that one thing should happen and the 
 compiler does something different, should we generally take the 
 spec to be correct, or should we take the compiler to be 
 correct? Do we need to ask Walter every time, or go spelunking 
 through github comments and the newsgroup to figure it out?

All of the above in unspecified order, sometimes fruitlessly, 
unfortunately.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 12/16/18 1:16 PM, Neia Neutuladh wrote:
 When the spec says that one thing should happen and the compiler does
 something different, should we generally take the spec to be correct, or
 should we take the compiler to be correct? Do we need to ask Walter every
 time, or go spelunking through github comments and the newsgroup to figure
 it out?
 
 When we want to change the compiler to be in line with the spec, does that
 require a DIP? When we want to change the spec to be in line with the
 compiler, does that require a DIP?
 
 The specific question here is whether attributes like  nogc should
 propagate into nested declarations the same as  trusted (as the spec says)
 or not (as the compiler implements).
 

Making rules about such things would necessitate accepting bad decisions 
for some of them. In essence, there are no hard-fast rules for things 
like this.

So I think it depends on the case. Just file the bug and see what the 
response is. I would expect the  nogc propagation would require a 
language change. Specifically, there's no good way to get the current 
behavior if you implement the propagation. So you need some way to turn 
off  nogc in order to make it more encompassing. But the fact that the 
spec says it should propagate probably increases the chances of a change 
getting accepted.

Ironically,  trusted can be overridden inside a struct, so it would have 
been nicer if that was the one that was mismatched...

-Steve

Neia Neutuladh <neia ikeran.org> writes:

On Sun, 16 Dec 2018 14:29:04 -0500, Steven Schveighoffer wrote:
 I would expect the  nogc propagation would require a
 language change.

A compiler change but not a spec change.

 Specifically, there's no good way to get the current
 behavior if you implement the propagation.

Your options:

1. Move your aggregates above the ` nogc nothrow pure:` line
2. Move your aggregates outside the ` nogc nothrow pure {}` block
3. Mark functions ` nogc nothrow pure` individually

 So you need some way to turn
 off  nogc in order to make it more encompassing.

That would be quite useful.

 But the fact that the
 spec says it should propagate probably increases the chances of a change
 getting accepted.

I'm not terribly confident.

Steven Schveighoffer <schveiguy gmail.com> writes:

On 12/16/18 2:42 PM, Neia Neutuladh wrote:
 On Sun, 16 Dec 2018 14:29:04 -0500, Steven Schveighoffer wrote:
 I would expect the  nogc propagation would require a
 language change.

 
 A compiler change but not a spec change.

Right.

 
 Specifically, there's no good way to get the current
 behavior if you implement the propagation.

 
 Your options:
 
 1. Move your aggregates above the ` nogc nothrow pure:` line
 2. Move your aggregates outside the ` nogc nothrow pure {}` block
 3. Mark functions ` nogc nothrow pure` individually

None of those are good options.

 
 So you need some way to turn
 off  nogc in order to make it more encompassing.

 
 That would be quite useful.

Agreed.

 
 But the fact that the
 spec says it should propagate probably increases the chances of a change
 getting accepted.

 
 I'm not terribly confident.
 

Well, I don't know if such a change is possible without fore-mentioned 
features to turn off  nogc. So it's one of those things where really I 
think the compiler should implement what the spec says, but the reality 
is that it would break too much code in a horrible way to make it a reality.

But the spec saying it should be that way gives more weight to the 
argument that it should be that way, even if it's painful.

-Steve

Adam D. Ruppe <destructionator gmail.com> writes:

On Sunday, 16 December 2018 at 21:32:50 UTC, Steven Schveighoffer 
wrote:
 the spec says, but the reality is that it would break too much 
 code in a horrible way to make it a reality.

If the spec says it and the code is not compliant, the code is 
*already broken*, by definition, and now the compiler is fixing 
its own bug that allowed invalid.

And I betcha a lot of people would be happy to see their hidden 
bugs now show up as a compile time error.


But that said, it is an embarrassing travesty that we don't have 
impure,  gc, virtual, throws, etc., to invert those things. Those 
NEED to be added ASAP if we want to have any sanity moving 
forward. With them, there is a sane transition/deprecation path 
to this bug fix among many other things, and we can write code 
that works in both cases by specifying either way.

Without them, the attributes suck regardless.

Neia Neutuladh <neia ikeran.org> writes:

On Sun, 16 Dec 2018 16:32:50 -0500, Steven Schveighoffer wrote:
 On 12/16/18 2:42 PM, Neia Neutuladh wrote:
 1. Move your aggregates above the ` nogc nothrow pure:` line
 2. Move your aggregates outside the ` nogc nothrow pure {}` block
 3. Mark functions ` nogc nothrow pure` individually

 
 None of those are good options.

I mean, yes, they're not super awesome. But it's also not like this is 
some unthinkably horrific thing that we're forced to use curly braces or 
reorder declarations sometimes -- we've been dealing with this with 
functions for years.

Unless there's some widespread tip running around to put a function inside 
a struct to reset  nogc and friends?

Stanislav Blinov <stanislav.blinov gmail.com> writes:

On Sunday, 16 December 2018 at 18:16:58 UTC, Neia Neutuladh wrote:

 The specific question here is whether attributes like  nogc 
 should propagate into nested declarations the same as  trusted 
 (as the spec says) or not (as the compiler implements).

On that topic specifically, I say no,  nogc shouldn't propagate. 
Unless we introduce a  nonogc. Because once you  nogc, you can't 
opt out.