[swift-evolution] [Draft] Target-specific CChar

[Dmitri Gribenko]

On Wed, Mar 2, 2016 at 11:10 AM, Joe Groff <jgroff at apple.com> wrote:
>
>> On Mar 2, 2016, at 11:06 AM, Dmitri Gribenko via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> On Wed, Mar 2, 2016 at 11:03 AM, William Dillon <william at housedillon.com> wrote:
>>> It does violate the principle of least astonishment, but we should
>>> acknowledge that the implementation-specific nature of C's char signedness
>>> is making code *less* portable, not more -- because the same code can mean
>>> different things on different platforms.  Reflecting the same in Swift makes
>>> Swift code less portable, too.
>>>
>>> Dmitri
>>>
>>> That is a fair point, and I agree for the most part.  However, It is my
>>> intent and expectation that the use of CChar would be limited to the margins
>>> where C APIs are imported.  Once values become a part of Swift (and used in
>>> places outside of the C interface) they should have been cast into a pure
>>> Swift type (such as UInt8, Int8, Int, etc).
>>
>> True, but how can you cast a CChar portably into UInt8 or Int8?  Only
>> via the bitPattern initializer, because the regular initializer will
>> trap on values outside of the 0..<128 range on signed platforms or
>> unsigned platforms.
>
> Could we treat CChar as a "signless" byte type, so that UInt8(cchar) and Int8(cchar) both just reinterpret the bit pattern?

That is viable, but it opens a whole another can of worms:

- we need CChar to be a separate type,

- other unlabelled integer initializers trap when changing the numeric
value, and this one would be wildly inconsistent.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/