[swift-evolution] [Draft] Target-specific CChar
william at housedillon.com
Wed Mar 2 13:26:15 CST 2016
On March 2, 2016 at 11:14:26 AM, Dmitri Gribenko (gribozavr at gmail.com) wrote:
On Wed, Mar 2, 2016 at 11:13 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> 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.
>>>> 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.
... but if we don't provide any arithmetic operations on the CChar
type, and treat it as an opaque byte-sized character type that you can
only convert to UInt8/Int8, it might not be bad!
I, to, like this solution. It would be moderately more work to transition to, but I think it’s better overall.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution