Introduce checking of ConcurrentValue conformances:
- For structs, check that each stored property conforms to ConcurrentValue
- For enums, check that each associated value conforms to ConcurrentValue
- For classes, check that each stored property is immutable and conforms
to ConcurrentValue
Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.
This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that refines ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.
The bulk of this change ended up being to the standard library, because
all conformances of standard library types to the ConcurrentValue
protocol needed to be sunk down into the standard library so they
would benefit from the checking above. There were numerous little
mistakes in the initial pass through the stsandard library types that
have now been corrected.
When the stdlib says not to check, it’s a good idea to actually not have any checking, so that we leave existing code paths unchanged. (And because we do trust that the stdlib is responsible about such things.)
Unchecked APIs must still perform checks in debug builds to ensure that invariants aren’t violated.
(I.e., these aren’t a license to perform invalid operations — they just let us get rid of the checks when we know for sure they are unnecessary.)
We can't actually check for NaN (because the notion doesn't exist for Comparable), but we can require that the endpoint is non-exceptional by checking if it equals itself.
The previous documentation of this operator in `Range` context was lost sometime during 2017. This new version is a simplified version of the original copy, with substantial inspiration taken from the present-day documentation of the same operator on `Optional`.
Fixes [SR-12842](https://bugs.swift.org/browse/SR-12842).
PR #20528 was merged yesterday, which inserts an `unreachable` in
functions with uninhabited parameters. Unfortunately this means any
statement in the function body, even ones that themselves are
never-returning or don't have any executable code, cause the warning.
Silence the warnings by deleting the bodies of these functions.
- 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
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:)
This implements the new last(where:), and lastIndex(of/where:) methods as
extensions on `BidirectionalCollection`, which partially implements SE-204.
The protocol requirements for `Sequence` and `Collection` as described
in the proposal need to wait until there's a solution for picking up the
specialized versions in types that conditionally conform to `BidirectionalCollection`.
- Make RawRepresentable Codable abstracts distinguishable
- Make the UnboundedRange example a little more user friendly
- Correct the RangeReplaceableCollection example description
- Revise CaseIterable discussion
Previously, both CountableRange and CountableClosedRange required
their bound types to be Strideable with a Stride type that conforms to
SignedInteger. Those constraints were not present on the generic
typealiases that replaced these structs. Add them back now, which
fixes the GRDB source compatibility regression.
Fixes https://bugs.swift.org/browse/SR-6907 / rdar://problem/29066394.
When implementing a protocol requirement, additional doc comments are
unnecessary unless there are additional semantics peculiar to the specific
implementation.
The manually propagated documentation had several problems, including copypasta
and inconsistent terminology.
Therefore, if `T.==` doesn't have any doc comments and the implementation of
`T.hashValue` is unremarkable, remove the unnecessary doc comment.
This assumes these will land in Swift 4.1; the attributes need to be adjusted if that turns out not to be the case.
It seems @available for protocol conformances is not yet functional. I added attributes for those anyway, marked with FIXME(conformance-availability).
# Conflicts:
# stdlib/public/core/ExistentialCollection.swift.gyb
# stdlib/public/core/Mirror.swift
* Add conditional Hashable conformance to Optional, Dictionary, Array, ArraySlice and ContiguousArray
* Modified hashValue implementations
The hashValues are now calculated similar to the automatically synthesized values when conforming to Hashable.
This entails using _combineHashValues as values of the collections are iterated - as well as calling _mixInt before returning the hash.
* Added FIXMEs as suggested by Max Moiseev
* Use checkHashable to check Hashable conformance
* Use 2 space indentation
* Hashing of Dictionary is now independent of traversal order
* Added a test to proof failure of (previous) wrong implementation of Dictionary hashValue. Unfortunately it does not work.
* Removed '_mixInt' from 'hashValue' implementation of Optional and Array types based on recommendations from lorentey
* Another attempt at detecting bad hashing due to traversal order
* Dictionary Hashable validation tests now detect bad hashing due to dependence on traversal order
* Removed superfluous initial _mixInt call for Dictionary hashValue implementation.
* Add more elements to dictionary in test to increase the number of possible permutations - making it more likely to detect order-dependent hashes
* Added Hashable conformance to CollectionOfOne, EmptyCollection and Range types
* Fix indirect referral to the only member of CollectionOfOne
* Re-added Hashable conformance to Range after merge from master
* Change hashValue based on comment from @lorentey
* Remove tests for conditional Hashable conformance for Range types. This is left for a followup PR
* Added tests for CollectionOfOne and EmptyCollection
* Added conditional conformance fo Equatable and Hashable for DictionaryLiteral. Added tests too.
* Added conditional Equatable and Hashable conformance to Slice
* Use 'elementsEqual' for Slice equality operator
* Fixed documentation comment and indentation
* Fix DictionaryLiteral equality implementation
* Revert "Fix DictionaryLiteral equality implementation"
This reverts commit 7fc1510bc3.
* Fix DictionaryLiteral equality implementation
* Use equalElements(:by:) to compare DictionaryLiteral elements
* Added conditional conformance for Equatable and Hashable to AnyCollection
* Revert "Use 'elementsEqual' for Slice equality operator"
This reverts commit 0ba2278b96.
* Revert "Added conditional Equatable and Hashable conformance to Slice"
This reverts commit 84f9934bb4.
* Added conditional conformance for Equatable and Hashable for ClosedRange
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
