Does the spec take priority over the compiler?
Steven Schveighoffer
schveiguy at gmail.com
Sun Dec 16 19:29:04 UTC 2018
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
More information about the Digitalmars-d
mailing list