https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124422
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Roland Illig from comment #5)
> From when I have learnt English, "may not" means "it is possibly false"
> while "must not" means "it has to be definitely false".
"may" has two meanings, it can denote a possibility but also permission. In
this context, "may not" means "is not permitted to" or "is not allowed to".
Which is subtly different from "it is not possible". The diagnostic is
referring to a rule from the C++ standard, which is about what is allowed and
not allowed (but arguably that *also* becomes what's impossible by extension,
because the compiler enforces what's not allowed).
ISO standards are supposed to be careful about "must" and "may not" for this
reason, although not everybody agrees with their suggested usage.
https://www.iso.org/sites/directives/current/part2/index.xhtml#_idTextAnchor082
https://www.iso.org/sites/directives/current/part2/index.xhtml#_idTextAnchor095
> "new types may not be defined" could thus mean that "in this case, it could
> happen that the new type is not defined, so the new type is effectively
> ignored". This misunderstanding is what I wanted to avoid.
I think "new types cannot be defined in a return type" would be better in this
case, but that is for the C++ front end maintainers to decide.
For `struct S{} func(void) { }` GCC currently says:
ret.cc:1:1: error: new types may not be defined in a return type
whereas Clang says:
ret.cc:1:8: error: 'S' cannot be defined in the result type of a function
That should probably be a separate bug for the C++ front end, since there's no
typo and the current wording was an intentional choice.
and EDG says:
"ret.cc", line 1: error: type definition is not allowed in function return type
