[stdlib] Replace #elseif with #else for 64-bit platforms

[xwu]

As discussed in #14386:

It seems unnecessarily fragile/verbose to list all supported 64-bit architectures[...]. We did go with #else in the new String implementation[...]

This PR removes the list of supported 64-bit architectures from non-test code in the standard library. (It'll be fine to continue testing only specifically enumerated architectures.)

[xwu]

@swift-ci Please smoke test

[lorentey]

I think this is a clear readability win with no drawbacks. The tests remain easily greppable in case we add new archs later.

It may be a good idea to annotate all these #ifs with a standardized comment to indicate that the intention was to test for the width of a machine word.

[jrose-apple]

:-( I'd push back against this. For low-level code, it's usually good to make explicit decisions about all new architectures.

EDIT: until we have a dedicated check for whatever the real query is here. (Do ILP64 arches count? LLP64?)

[gparker42]

I agree with Jordan. Porting is hard.

The String code in #14386 was able to use #else because that clause generates a build-time error if done incorrectly. That is not the case for at least some of the changes involved here.

[lorentey]

Fair enough! I agree a dedicated conditional would be much preferable.

I think Swift's Int type is defined to match the size of a pointer, so we don't need to distinguish between LP64/ILP64/LLP64 in any of these cases.

[jrose-apple]

Yes, Int matches the size of a pointer. I just meant in general people aren't always clear about what they're actually testing for. (We had a bunch of __LP64__ in the C++ bits of the runtime that @compnerd had to fix to __POINTER_WIDTH__ == 64 to get Windows to work.)

[lorentey]

What if we introduced a _pointerwidth(n) conditional, then? It'd make the intention explicit:

#if _pointerwidth(32)
  return Int(Int32(bitPattern: rand32()))
#elseif _pointerwidth(64)
  return Int(Int64(bitPattern: rand64()))		
#else
  fatalError("unimplemented")
#endif

(We currently call this word_bits in gyb.)

[jrose-apple]

That's @xwu's #14413. As I said there, I'm reluctant to do something like that without going through Evolution. But I could be overruled.

[xwu]

I'll close this PR in favor of continuing discussion on #14413.