This is primarily for documentation purposes, although the default implementation (based on an iterator) may not return the correct value for bridged dictionaries with exotic implementations.
- Inlinability audit
- Create a _NativeSet/_NativeDictionary directly, without extracting it from a Set/Dictionary
- Swap the final result with an empty collection.
- Nest native/cocoa index types under their corresponding struct
- Move *IndexRepresentation enums under the corresponding Index type, renamed to _Variant.
- Rename Index._value to Index._variant.
- Remove internal typealiases.
- Remove underscore prefix from enum case names.
- _nativeIndex => _asNative, _cocoaIndex => _asCocoa
- Audit inlinability.
- Rename variant enum types and move them into the corresponding struct:
_VariantSetBuffer => Set._Variant
_VariantDictionaryBuffer => Dictionary._Variant
I found the buffer suffix did not positively contribute to understanding these types. And the extra indirection of the typealiases wasn't exactly helpful, either.
- Remove internal typealiases that resolved to these.
- Fix error in `last(where:)` example
- Improve MemoryLayout, UnsafePointer, and integer operator discussions
- Clean up ranges and random APIs
- Revisions to overflow operators and the SignedNumeric requirements
- Standardize on 'nonoptional' in remaining uses
* Update std lib to Swift 5.0
* Disable Unicode.* warnings for now
* Slow path to resiliently handle the case where an unknown rounding rule is passed
* Remove resilience from Encoding/DecodingError (which should only happen on slow paths anyway)
* internal typealiases now need @usableFromInline
* Force inlining on Array._owner.get
This allows Set’s internal types not to define Key, Value, SequenceElement & SequenceElementWithoutLabels typealiases.
Splitting the protocol on the mutable/immutable axis allows us to remove some obsolete method definitions.
This breaks out of the loop immediately when the last slot has been filled in the output buffer, skipping a final sequence of iterations over empty buckets.
Dictionary’s native storage classes and _SwiftDeferredNSDictionary override -[NSDictionary getObjects:andKeys:] instead of its safer replacement, -[NSDictionary getObjects:andKeys:count:].
Overriding the correct method will considerably speed up some Cocoa operations on bridged dictionaries.
rdar://problem/39285882
AnyHashable has numerous edge cases where two AnyHashable values compare equal but produce different hashes. This breaks Set and Dictionary invariants and can cause unexpected behavior and/or traps. This change overhauls AnyHashable's implementation to fix these edge cases, hopefully without introducing new issues.
- Fix transitivity of ==. Previously, comparisons involving AnyHashable values with Objective-C provenance were handled specially, breaking Equatable:
let a = (42 as Int as AnyHashable)
let b = (42 as NSNumber as AnyHashable)
let c = (42 as Double as AnyHashable)
a == b // true
b == c // true
a == c // was false(!), now true
let d = ("foo" as AnyHashable)
let e = ("foo" as NSString as AnyHashable)
let f = ("foo" as NSString as NSAttributedStringKey as AnyHashable)
d == e // true
e == f // true
d == f // was false(!), now true
- Fix Hashable conformance for numeric types boxed into AnyHashable:
b == c // true
b.hashValue == c.hashValue // was false(!), now true
Fixing this required adding a custom AnyHashable box for all standard integer and floating point types. The custom box was needed to ensure that two AnyHashables containing the same number compare equal and hash the same way, no matter what their original type was. (This behavior is required to ensure consistency with NSNumber, which has not been preserving types since SE-0170.
- Add custom AnyHashable representations for Arrays, Sets and Dictionaries, so that when they contain numeric types, they hash correctly under the new rules above.
- Remove AnyHashable._usedCustomRepresentation. The provenance of a value should not affect its behavior.
- Allow AnyHashable values to be downcasted into compatible types more often.
- Forward _rawHashValue(seed:) to AnyHashable box. This fixes AnyHashable hashing for types that customize single-shot hashing.
https://bugs.swift.org/browse/SR-7496
rdar://problem/39648819
- Clarify RawValue requirement for OptionSet
- Make Bool counterexample more clearly an error
- Add clarifying note about unsafe arithmetic methods
- Add/refine complexity docs for sequence/collection
- Remove docs from obsoleted symbols
- Standardize on unicode.org for links about Unicode
- More complexity annotations
- Expand dictionary defaulted subscript docs
- Fix error in Dictionary.init(minimumCapacity:) docs
- Improve accuracy of prime number listing
@effects is too low a level, and not meant for general usage outside
the standard library. Therefore it deserves to be underscored like
other such attributes.
As a general rule, it is safe to mark the implementation of hash(into:) and _rawHashValue(seed:) for @_fixed_layout structs as inlinable.
However, some structs (like String guts, Character, KeyPath-related types) have complicated enough hashing that it seems counterproductive to inline them. Mark these with @effects(releasenone) instead.
This includes various revisions to the APIs landing in Swift 4.2, including:
- Random and other randomness APIs
- Hashable changes
- MemoryLayout.offset(of:)
