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

If it doesn't match bug report.

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.

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 :)

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

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.

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.

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.

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

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.