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, Apple Developer Documentation which clearly indicates that it is supposed to be sizeof(void *) and seems that therefore intBitWidth would be superfluous?
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.
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.
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.