[swift-evolution] [proposal]Decouple definition of Int8 from target char type

[Dmitri Gribenko]

On Mon, Feb 29, 2016 at 10:43 AM, William Dillon
<william at housedillon.com> wrote:
>> that the dual-meaning of Int8 is expected and intended, otherwise the
>> author of this comment and code (Ted and Jordan respectively) don’t
>> understand the intended behavior, and I find that hard to believe.
>
> No, it isn't intended. This typealias should be conditionally defined
> as either Int8 or UInt8, depending on the platform. That's what the
> comment says, but it is not implemented in code, because we didn't
> have a port of Swift to a platform where that code was incorrect.
>
>
> Ok, if that’s the case, I’ll write up the draft to the proposal.  I think we
> agree on 80% of the concepts at this point.

I'm glad that we reached understanding :)  I think fixing the bug and
porting the code to the new API would be a good test for this change
(both from the implementation standpoint, and API-wise).

But there's still a question of what is a better user model.  In the
other thread, Joe noted that we had the same issue with CGFloat.  It
used to be a typealias to Double on some platforms, and Float on other
platforms.  We found that in practice, it was hard for developers to
write cross-platform code.  Developers followed the guidance from the
type checker, and made the code compile for their primary platform,
relying on CGFloat to be identical to Double or Float.  The code
typically didn't compile for other platforms.

It would be great if we could try fixing the bug with the CChar
typealias (to make its definition platform-dependent), and see how bad
the problem with cross-platform code is in practice.  Maybe CChar is
not like CGFloat at all.

Another possible model that I would like to suggest is to make 'char'
always import as Int8 or UInt8, consistently across all platforms.
The rationale is that if the C code is relying on numeric values
outside of the portable 0..<128 range, and is requiring the API
clients to perform numeric operations on those values (that is, the
numeric values are important, not just the bit pattern), then the
corresponding Swift code won't be portable anyway, and introducing
CChar won't fix anything (since CChar won't be able to provide
arithmetic operations).

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>*/