Repository navigation
[cstdint.syn.2] is not in line with intention #3521
Description
Activity
I think this is the subject of long-standing library issue http://wg21.link/lwg2820, which is just never quite important enough to be handled. But we should definitely make some changes here. I venture to say that those aren't editorial, though, and should be handled by LWG.
@tkoeppe I don't think it's the same as (pun intended) that, and I do think it's editorial.
The topic of this issue is not the macros, which can't be in or out of namespace std anyway, because they're macros. The issue is that "the same as" suggests "declares the same types, in the same namespace" i.e.
<cstdint>is required to put the types in the global namespace. That is not the intent of those words, and so clarifying it seems editorial to me.Reacted by Dawid PilarskiWhat the words mean is that after including both
<cstdint>and<stdint.h>,std::same_as<std::int_least32_t, ::int_least32_t>is true. i.e. the implementation is not allowed to definestd::int_least32_taslongif::int_least32_tisint. It is only saying the typedefs must refer to the same underlying types, not that "all the same declarations are provided, in the same namespaces".In such case, the wording would be more like:
All definitions of types in this header are the same as corresponding types from the C standard library header <stdint.h>.
then it makes distinction of the two types.
namespace std{ struct S{}; }struct S{};are different definitions
Or "every typedef declared in this header denotes the same type as the corresponding typedef in the C standard library header
<stdint.h>". Maybe we just want that as a blanket statement for all the<cxxx>headers. We never want to allow e.g.std::max_align_tto be different to::max_align_t.Reacted by Dawid Pilarski, Thomas Köppe, Michał Dominiak and Jens Maurer@jwakely: yes, good point, thanks. I always took "same as" to mean that "the type defined by the alias is the same type (not type name!) as that defined by C; I didn't interpret "same as" to appertain to the declarations. The clarification seems useful (though I also don't think it's terribly misleading at the moment).
Should I create PR with @jwakely wording for that?
Sure, go ahead (with the "blanked wording for all
<cxxx>headers" approach).pull request created:
#3528Is there really an issue?
[extern.types]/1 (has been existing since C++98) reads:
For each type
Tfrom the C standard library, the types::Tandstd::Tare reserved to the implementation and, when defined,::Tshall be identical tostd::T.
I find
to not fully reflect the intention as the
would mean, that cstdint also needs to define non std:: version of aliases. This is also against:
[library.5]
I propose to reword the [cstdint.syn.2] or remove it (since library.5 already handles this case).
In case of rewording it could sound like: