Compilation conditions for word size

I still feel like there has been no case made for why the intBitWidth or wordBitWidth is needed, merely a statement that this is needed because Foundation uses architecture lists to determine which size to use. It seems that in all of those cases, its pointer size that they are checking for and no concrete examples have been given for intBitWidth and wordBitWidth. Did I just happen to completely gloss over that?

For the intBitWidth, which clearly indicates that it is supposed to be sizeof(void *) and seems that therefore intBitWidth would be superfluous?

1 Like

This actually makes me wonder—in our brave new ASTGen world, will #if be evaluated in the parser or in ASTGen? @rintaro @jansvoboda11

In any case, I wonder if we could support only lookup of the size of types in a different module. That would suffice to get the size of Int or CGFloat without needing to fully parse the surrounding code. We could even require the name to be fully qualified so that it's not sensitive to imports or anything else in the current module:

#if sizeof(Foo_is_16.Foo) == 8    // No way to create circular shenanigans

I'm not sure whether #if is currently evaluated in Parser, but if so, we'll move the evaluation to ASTGen. The idea is that the parser should be strictly concerned only with parsing and any semantic actions should be done at a later stage.


Looking through swift-corelibs-foundation for uses of #if arch, it seems that most cases are not concerned with pointer size as such, but Int size.

We see it in Data, in NSNumber, in NSRange and in Scanner.

Looking through Github projects, #if arch seems to often be used in tests for testing precision or maximum values.

I'm all in favour of having separate conditionals for Int size and pointer size, and possibly other word sizes as well.

The APIs on Unsafe*Pointer and Int were designed assuming they're the same size, so it'd be a bigger project to separate them.

1 Like

If that is the assumption built into Swift, we should perhaps just expose a corresponding conditional. Switching on a growing list of architectures handles neither case.

Meanwhile, TSPL states:

Swift provides an additional integer type, Int , which has the same size as the current platform’s native word size


Yeah. TSPL is the one out of line here; when we hit our first platform with pointers different from "native word size" (arm64_32), we said Int matches pointers.


"Word" has never been an unambiguous term, which is one reason why we don't normally use it in the library or in documentation.

Pointer size is also a surprisingly complex concept: in addition to targets like arm64_32 or x32 with artificially restricted address spaces, there are interesting targets (such as GPUs) with non-unified address spaces, as well as various proposals to use fat pointers for security hardening (which can mean that the range of pointers can be substantially smaller than their storage size).

Regardless, Swift makes an assumption in several places that the target has an acceptable generic address space which class references, UnsafePointers, etc. must fall within. That choice of address space is a core and immutable aspect of the definition of the target, and if we wanted to support e.g. wide pointers on arm64_32 then we would need to provide new language mechanisms to access that wider range.

I have always considered Int to be tied to the range of that generic address space, and I am fairly certain that the library team agrees, and that is reflected throughout Swift's API. I don't know if we've ever said anything about that officially, but if we haven't, I'd be happy to run that statement past the rest of the Core Team, and I don't think we'd hesitate about it. Given that, I don't think we should provide redundant ways to query the range of Int vs. pointer size.


I also don't speak for the core team, but FWIW, I wholeheartedly agree with you and +1 this viewpoint. Int really needs to follow the UnsafePointer size, and if a specific target chooses to use a constrained pointer size, that constraint should apply to Int as well IMO.


Terms of Service

Privacy Policy

Cookie Policy