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? > >> 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. >> >> 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. Yeah, my proposed change wouldn't be sufficient. It would need to say something about using explicit signed/unsigned qualifications for char. > >> >>> 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 > >>>
