[swift-evolution] [Draft] Introducing Build Configuration Tests for Platform Conditions
shawnce at gmail.com
Tue Mar 15 15:40:34 CDT 2016
Thanks! ...that muddies the water for me more. :)
Who are the users of these platform conditionals? I would assume most
likely folks that are interfacing swift code with C code? In side of the
Swift "sandbox" you should be isolated otherwise, right?
If that is the case then the width of various C types change depending on
OS/OS variant, CPU architecture and potentially other factors. It seems
like conditional evaluating the size of given standard C type may be needed?
On Tue, Mar 15, 2016 at 1:15 PM William Dillon <william at housedillon.com>
> Here’s an example of the kind of thing that’s common: 22 days ago
> There’s another good one in NSRange:
> There are FAR too many to list in stdlib, runtime, and (compiler) tests.
> - Will
> On Mar 15, 2016, at 10:06 AM, Shawn Erickson <shawnce at gmail.com> wrote:
> On Tue, Mar 15, 2016 at 9:51 AM William Dillon <william at housedillon.com>
>> The vast majority of special cases I’ve seen and written are due to the
>> size of Int, not a pointer per se. To clear up the confusion, how about we
>> rename bitwidth to intwidth or intsize?
>> - Will
>> > On Mar 15, 2016, at 9:40 AM, Shawn Erickson via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> > I guess the fuzziness in my mind is when considering LP64, LLP64, etc.
>> I believe swift attempts to avoid that by defining either 32 bit or 64 bit
>> model. If that is universally the case then I think bitwidth is fine. If
>> not then pointerwidth may be more correct. Those bridging to C would have
>> to consider information from the C world to deal with the variations of
>> type size based on platform and 32/64.
> I am curious to see some examples of checking Int size to better
> understand the situation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution