This abbreviation for "if and only if" is confusing to those not coming
from a background in formal mathematics, and is frequently reported as a
type by developers reading the documentation.
This commit also changes doc comments in internal and private members,
which don't become part of the public documentation, because omitting
"iff" everywhere makes it much easier to check for any later changes
that reintroduce it.
The find functions do not require the generic Value parameter. Moving them to __RawDictionaryStorage allows to define them with only one generic parameter: the Key.
This allows the optimizer to share specializations for dictionaries which have the same Key, but a different Value.
Also, prevent inlining of the find-functions to save some additional code size.
Old Swift and new Swift runtimes and overlays need to coexist in the same process. This means there must not be any classes which have the same ObjC runtime name in old and new, because the ObjC runtime doesn't like name collisions.
When possible without breaking source compatibility, classes were renamed in Swift, which results in a different ObjC name.
Public classes were renamed only on the ObjC side using the @_objcRuntimeName attribute.
This is similar to the work done in pull request #19295. That only renamed @objc classes. This renames all of the others, since even pure Swift classes still get an ObjC name.
rdar://problem/46646438
The first change is to remove some @inline(__always) attributes. Those were added before we had the guaranteed-by-default calling convention. They are not necessary anymore.
The second change is to not specialize some slow-path functions. This results that no specialization code for these functions is generated at the client side. Instead those functions are directly called in the libSwiftCore.
Note that Key-related hash and equality comparisons are still specialized, because otherwise the performance hit for Osize would be too big.
Some Dictionary benchmarks regress a bit with -Osize, but the code size wins are big.
rdar://problem/46534453
_modify mustn’t leave Collection storage in an inconsistent state when the code to which we’re yielding happens to throw. In practice this means that any cleanup code must happen in defer blocks before the yield.
Fix Dictionary to do just that and add tests to cover this functionality (as well as some other aspects of _modify).
These should be audited since some might not actually need to be
@inlinable, but for now:
- Anything public and @inline(__always) is now also @inlinable
- Anything @usableFromInline and @inline(__always) is now @inlinable
This eliminates a retain/release pair around calls to it when it doesn’t get inlined.
_delete is responsible for restoring hash table invariants after a removal. It moves around elements in complicated patterns, but it doesn’t release them.
Replacing the old key with the new is unnecessary and somewhat surprising. It is also harmful to some usecases.
rdar://problem/32144087
# Conflicts:
# stdlib/public/core/NativeDictionary.swift
Affected operations:
subscript(index:)
keys.subscript(index:)
values.subscript(index:) (setter and _modify)
remove(at:)
swapAt(_:, _:)
Note that index(after:) is intentionally not on this list.
