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? bitwidth(cptr: 32/64) bitwidth(cint: 32/64) bitwidth(clong: 32/64) bitwidth(cdouble: 32/64) etc. -Shawn On Tue, Mar 15, 2016 at 1:15 PM William Dillon <[email protected]> wrote: > Here’s an example of the kind of thing that’s common: 22 days ago > <https://github.com/apple/swift-corelibs-foundation/pull/264/files#r53730929> > There’s another good one in NSRange: > https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSRange.swift#L90-L94 > There are FAR too many to list in stdlib, runtime, and (compiler) tests. > > - Will > > On Mar 15, 2016, at 10:06 AM, Shawn Erickson <[email protected]> wrote: > > On Tue, Mar 15, 2016 at 9:51 AM William Dillon <[email protected]> > wrote: > >> 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 < >> [email protected]> 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. > > -Shawn > > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
