Does the spec take priority over the compiler?

[Steven Schveighoffer]

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