Travis Vitek wrote:
Martin Sebor wrote:
Are you sure the traits are correct for char and wchar_t?
No.
Also, do you believe the working draft to be
unambiguous and correct?
No. For reference, I've pulled the requirements from the standard and
pasted them below.
There is at least one obvious ambiguity. Assume that char is signed.
Should std::make_signed<unsigned char>::type be 'char' or 'signed char'?
Yes. This needs to be clarified. Could you bring it up on
[EMAIL PROTECTED] to make sure it's not a known problem
that's already being handled? I'll help you write up the
issue if it isn't.
Same goes for std::make_signed<enum_t>::type when sizeof(enum_t) ==
sizeof(char). If both 'char' and 'signed char' are signed integral
types, which of the two should be used?
I didn't think enums could be smaller than int but that's
probably going to change with scoped enums.
It also seems wrong to have std::make_signed<char>::type be 'signed
char' only when 'char' is unsigned. It seems that users would like to be
able to expect that the resulting type be consistent regardless of the
signed-ness of char.
Sounds like a valid point to me. OTOH, the actual type may
not matter all that much just as long as the signedness is
right. In my experience, in the handful of cases when I've
ever needed an unsigned form of a (possibly) signed type
all I cared about was the absence of signedness.
Both of these issues make me think that the definition of make_signed
should have said 'signed integer type' instead of 'signed integral
type'.
You mean just signed/unsigned integers (I had to look up the
difference). I suspect most people would find a make_signed
that didn't work with char to be broken.
Based on my reading, make_signed<T>
::type should be the same as T if T is a signed integral type.
IIUC, our make_signed<char>::type is defined to signed char
regardless of the signed-ness of char. Ditto for wchar_t.
Right. That's what caught my attention because it goes
against the requirement.
Martin
[basic.fundamental] p2
There are five standard signed integer types: "signed char",
"short int", "int", "long int", and "long long int". In this
list, each type provides at least as much storage as those
preceding it in the list. [...] The standard and extended
signed integer types are collectively called signed integer
types.
[basic.fundamental] p3
For each of the standard signed integer types, there exists
a corresponding standard unsigned integer type: "unsigned
char", "unsigned short int", "unsigned int", "unsigned long
int", and "unsigned long long int", each of which occupies
the same amount of storage and has the same alignment
requirements as the corresponding signed integer type. [...]
The standard and extended unsigned integer types are
collectively called unsigned integer types.
[basic.fundamental] p7
Types bool, char, char16_t, char32_t, wchar_t, and the signed
and unsigned integer types are collectively called integral
types.
[meta.trans.sign]
If T names a (possibly cv-qualified) signed integral type then
the member typedef type shall name the type T; otherwise, if T
names a (possibly cv-qualified) unsigned integral type then type
shall name the corresponding signed integral type, with the same
cv-qualifiers as T; otherwise, type shall name the signed
integral type with smallest rank for which sizeof(T) ==
sizeof(type), with the same cv-qualifiers as T.
