Travis Vitek wrote:
Martin Sebor wrote:
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.
Okay. How formal is this list? Can I just post a quick message showing a
testcase and asking if the issue is known, or should I go through the
trouble to pull all of the necessary quotes from the draft, proposal and
papers?
You don't need to quote the spec like you did here. A small
test case is always nice, although in this case, I'm not sure
it's necessary. All we need to know, I think, is whether
make_signed<T>::type is intended to be signed char or plain
char if T is char and CHAR_MIN < 0, and what the intended
effects are for T being wchar_t. And maybe also for T being
an enumeration.
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.
If I'm reading the standard correctly, specifically decl.enum p4 and 5,
it seems that it is allowed.
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.
Sure, but it would be nice if there was a requirement.
Absolutely!
Martin
