Due to an unstable (and undesirable) calling convention in the LLVM layer for x86, I had previously marked Float16 unconditionally unavailable on macOS. My hope was that Intel would stabilize the calling convention and we could make it available on both macOS platforms at the same time. Unfortunately, that hasn't happened, and we want to make the type available for macOS/arm users.
So, I am making the availability mirror Float80--the type will be unavailable for macOS on x86_64, and available on all other platforms (the other x86 platforms don't have a binary-stability guarantee to worry about). This isn't ideal. In particular, if/when the calling conventions for Float16 stabilize in LLVM, we would want to make the type available, but it would then have _different_ availability for different architectures of macOS, which the current availability system is not well-equipped to handle (it's possible, but not very ergonomic). Nonetheless, this seems like the best option.
The good news is that because the full API is already built in Swift (and simply marked unavailable), we can simply add macOS 11.0 availability for these API and it will work.
LLVM doesn't have a stable ABI for Float16 on x86 yet; we're working with Intel to get that fixed, but we don't want to make the type available on macOS until a stable ABI is actually available, because we'd break binaries compiled before any calling convention changes if we do.
In particular, types generic on the CodingKey produce a lot of runtime metadata.
Reducing the number of such types should help with some of the reported memory
bloat from Codable.
Based on a suggestion of @jckarter
Resolves rdar://62620208
Array, Set, Dictionary, and Optional all provide unconditional conformances
to Encodable & Decodable that dynamically check whether their type arguments
are Encodable/Decodable. Now that we have conditional conformances, make
these unconditional conformances properly conditional, removing all of
the Swift 4-era type-erasure hacks.
Fixes rdar://problem/34989162.
As a temporary workaround for SR-5206, certain Foundation types which had custom behavior in JSONEncoder and JSONDecoder were granted special knowledge of those types internally in order to preserve strategies on encode/decode.
This replaces that special knowledge with a more general-purpose fix that works for all types and all encoders/decoders.
- Revisions to unsafeDowncast and withVaList
- Fix the Int64/UInt64 discussion
- Buffer pointer revisions
- Fix Optional example to use new integer methods
- Revise and correct some UnsafeRawBufferPointer docs
- Fix symmetricDifference examples
- Fix wording in FloatingPoint.nextDown
- Update ImplicitlyUnwrappedOptional
- Clarify elementsEqual
- Minor integer doc fixes
- Comment for _AppendKeyPath
- Clarification re collection indices
- Revise RangeExpression.relative(to:)
- Codable revisions
For the benefit of unkeyed containers, coding paths currently contain optional `CodingKey`s — unkeyed containers are allowed to report a `nil` key in a path. However, this is unhelpful for debugging purposes, or inspecting the coding path for context, since any unkeyed container simply reports `nil`, whether it’s at index 1 or 1000.
Now all containers are required to report a non-optional CodingKey for their segment of the coding path, and coding paths are now exposed as `[CodingKey]`.
CustomNSError briding only works when the CustomNSError conformance is in the same module as the original error declaration. We need to sink these down into the standard library.
* Add encodeNil(forKey:)/encodeNil() for keyed/unkeyed encoding
containers
* Add decodeNil(forKey:)/decodeNil() for keyed/unkeyed decoding
containers
* Give default implementation of decodeIfPresent(forKey:)/
decodeIfPresent(_:) on keyed/unkeyed decoding containers instead of
decode(forKey:)/decode(_:)
* Expose all encode/decode methods on keyed encoding & decoding
containers to allow overriding default methods (which were previously
not forwarding)
* Adds conformance of Optional to Codable
* encode(...) arguments are no longer Optional; Optional values go
through generic version
* encodeIfPresent added to KeyedEncodingContainerProtocol to mirror
decodeIfPresent
* JSONEncoder and PropertyListEncoder updated to reflect these changes
- remove additional 'characters' references from String docs
- improved language around escaping pointer arguments
- key path type abstracts
- codable type abstract revisions
- a few more NSString API fixes
The box types were previously fileprivate because they lived in
the Foundation overlay. As part of the Swift stdlib, though, they need
to be internal so they can be linked against.
You shouldn't need to be Codable in order to get these implementations;
being either Encodable or Decodable should be enough to get the relevant
default implementation
