CWG2689 [basic.fundamental] Clarifying that std::nullptr_t is a fundamental type even though it is defined in header cstddef by changing the non-normative note to a clause

[ranaanoop]

Full name of submitter (unless configured in github; will be published with the issue): Anoop Rana

Reference (section label): [basic.fundamental]

Link to reflector thread (if any):

Issue description:

Currently basic.fundamental#14 says:

A value of type std​::​nullptr_­t is a null pointer constant. Such values participate in the pointer and the pointer-to-member conversions ([conv.ptr], [conv.mem]). sizeof(std​::​nullptr_­t) shall be equal to sizeof(void*).

(emphasis mine)

Note the emphasis on the term "value". My point is that the above clause seems to be mainly talking about "value" instead of "type" while it should be mainly talking about the "type" std::nullptr_t which is defined in cstddef.syn inside namespace std.

This matters because basic.fundamental#15 says:

The types described in this subclause are called fundamental types. [ Note: Even if the implementation defines two or more fundamental types to have the same value representation, they are nevertheless different types. — end note ]

(emphasis mine)

Again note that the above clause talks about "types described" instead of "types of values described" in this subclause. Though this doesn't seem to be a big problem as one can assume that "types described" is the same as "types of value described", I suggest that we should instead move atleast part of the non-normative note to basic.fundamental#14.

Suggested resolution:

Change basic.fundamental#14 to as highlighted(in bold) below:

std​::​nullptr_­t is a distinct type that is neither a pointer type nor a pointer-to-member type. A value of type std​::​nullptr_­t is a null pointer constant. Such values participate in the pointer and the pointer-to-member conversions ([conv.ptr], [conv.mem]). sizeof(std​::​nullptr_­t) shall be equal to sizeof(void*)..

As we can see the note from lex.nullptr is taken and is added into basic.fundamental#14.

---

Moroever if needed a separate note can be added into basic.fundamental#15 saying as highlighted(in bold) below:

The types described in this subclause are called fundamental types.
[ Note: Even if the implementation defines two or more fundamental types to have the same value representation, they are nevertheless different types. — end note ]
[Note: Even though std::nullptr_t is declared in cstddef, it is still considered a fundamental type --end note]

Note that the above added note is the second change that this issue suggests.

[JohelEGP]

A prvalue of this type is a null pointer constant and can be converted to a null pointer value or null member pointer value. See [conv.ptr] and [conv.mem].

That's a reiteration of the earlier sentence https://timsong-cpp.github.io/cppwp/n4861/basic.fundamental#14.sentence-2.

[ranaanoop]

@JohelEGP I've removed that reiteration. Check out my updated suggested resolution. Thanks for pointing that out.

[frederick-vs-ja]

std::nullptr_t is not defined in any header. In C++, a (non-template) typedef-name is merely declared and never defined ([basic.def]/2.9, [basic.def]/2.10).

[ranaanoop]

std::nullptr_t is not defined in any header. In C++, a (non-template) typedef-name is merely declared and never defined ([basic.def]/2.9, [basic.def]/2.10).

@frederick-vs-ja Did you perhaps missed cstddef.syn which says:

Header <cstddef> synopsis

namespace std {
 using nullptr_­t = decltype(nullptr);

 //other things here
}

---

I think your point is that using nullptr_t = decltype(nullptr); is a declaration and not a definition according to [basic.def]/2.10 in which case the 2nd suggestion in my issue should be changed to as highlighted below(in bold):

The types described in this subclause are called fundamental types.
[ Note: Even if the implementation defines two or more fundamental types to have the same value representation, they are nevertheless different types. — end note ]
[Note: Even though std::nullptr_t is declared in cstddef, it is still considered a fundamental type --end note]

Note that I've changed the term "defined" to "declared" in my above modified suggestion.

[ranaanoop]

@frederick-vs-ja I've changed the term "defined" to "declared" in the 2nd suggestion(which is a note) of my original issue as well. Check out the updated wording.

[AlanVoore]

@jensmaurer I think the intention(of the current standard's wording) is to have std::nullptr_t as a fundamental type(aka built in type). So this issue's resolution does make sense. Although I've seen people saying that std::nullptr_t is not a fundamental type. The additions mentioned here will help clarify the same.

[frederick-vs-ja]

I guess the original issue can be resolved as editorial (i.e., a PR to cplusplus/draft is suitable).

However, I'm afraid that the currently proposed note is problematic. A parallel statement - "Even though std::int32_t is declared in <cstdint>, it is still considered a fundamental type." - seems confusing. I believe that a fundamental type itself is not declared anywhere, only the typedef-name denoting it can be declared.

BTW, there seems another issue - cv-qualified versions of std::nullptr_t are not mentioned in [basic.fundamental].

[jensmaurer]

CWG2689

I'm not seeing a need to normatively say that std::nullptr_t is not a pointer or pointer-to-member type. The former is a fundamental type, the latter are compound types.

[ranaanoop]

I'm not seeing a need to normatively say that std::nullptr_t is not a pointer or pointer-to-member type. The former is a fundamental type, the latter are compound types.

@jensmaurer AFAIK both are compound types as per basic.compound-1.3 and basic.compound-1.8. Moreover, cppreference's documentation on types also says that std::nullptr_t is a fundamental type and both a pointer as well as a pointer-to-member type are compound types. This means that there is no problem in saying normatively that std::nullptr_t is not a pointer or pointer-to-member type since both the former and the latter are compound types.

Perhaps I missed something here or you overlooked this?

[jensmaurer]

@ranaanoop , I feel there is a communication disconnect.

I said that cv std::nullptr_t is a fundamental type. I also said that a pointer type is a compound type, as is a pointer-to-member type. By virtue of having different type categories (fundamental vs. compound), a std::nullptr_t can't possibly be a pointer type or a pointer-to-member type, and thus we don't have to repeat that explicitly normatively. The note we have elsewhere is good enough.

[ranaanoop]

@jensmaurer Oh, I see when you said "former" I thought you meant "pointer" and when you said "latter" you meant "pointer to member" but that was not the case. In particular, by "former" you actually meant std::nullptr_t and "latter" was for "pointer as well as pointer to member". I misread that comment of yours. Thanks for clarifying.

Regards