There are a couple of features that are not yet implemented, because they require additions to the Builtin module. Specifically, this implementation does not have:
- formRemainder(dividingBy:)
- formSquareRoot()
- addProduct(_:,_:)
Also missing are the generic initializers and comparisons whose implementation depends on having new Integer protocols.
The last remaining feature of SE-0067 is that while the basic operators +,-,*,/, etc are moved onto the FloatingPoint protocol, they are still required on the concrete types in order to disambiguate overloads. Fixing this seems to require either modifying the overload resolution rules or removing these operators from some other protocols. Or it might just require that someone smarter than me looks at the problem.
Passes all the existing tests (with the included changes). I'm working on additional tests for the new features.
Removing the “checksAdded” parameter from collection unit tests and
simply sharing a global variable is a better way to go. We don't
use threads at that level, so there's no thread safety issue, and we
already committed to globals when we introduced the logging wrappers.
The defaults we were generating for Collection and
BidirectionalCollection didn't make any sense, because if you could do
that strideable arithmetic then you essentially had random access.
Instead we constrain the defaults to apply to RandomAccessCollection
where the Indices are a CountableRange.
Add Android to the OS checks used to determine whether to import Glibc.
These tests would pass on Android were it not for the fact that Android is not
included in the Glibc check.
Also add FreeBSD where missing.
The RangeProtocol was a very weak and fragile abstraction because it
didn't specify the interpretation of the endpoints. To write a
non-trivial algorithm, one usually needed to consult that information.
The standard library code only actually worked correctly with half-open
and closed ranges (and didn't handle fully open ranges, for example).
The other two protocols, HalfOpenRangeProtocol and ClosedRangeProtocol,
were only used for code sharing, and present an ABI burden. We can use
gyb instead.
The cases where the limit was in the opposite direction of the movement
were not being tested. Also, bring back the explicit expected result.
Some things are not as trivial to compute correctly as they look.
A number of factors were making it hard to tell what was being tested
here. This commit improves naming, and stops explicitly specifying
expected results that can be trivially computed.
