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
>c++std-lib@accu.org 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
>
>>>
|