An optimization should be added in order for the new one to be
efficient, i.e. if the `count` value is equal to `1`, the underlying
`Builtin.destroy` should be called, instead of
`Builtin.destroyArray`.
- Remove free Swift functions for advance and distance and replace
them with protocol extension methods:
- advancedBy(n)
- advancedBy(n, limit:)
- distanceTo(end)
- Modernize the Index tests
- Use StdlibUnittest
- Test for custom implementation dispatch
Perf impact: No significant changes reported in the
Swift Performance Measurement Tool.
rdar://problem/22085119
Swift SVN r30958
(or in 'randomShuffle')
This violates our inout aliasing rules, and can cause a crash in certain
situations.
To try to prevent this in the future I've added a debugPrecondition check
to 'swap' that checks addresses. This will only catch inout violations
where neither argument uses writeback, and might some day be optimized
away. Right now, though, it does seem to catch some simple violations
(though not the one in the Radar), so hopefully it will at least help keep
us from introducing new problems.
rdar://problem/21780567
Swift SVN r30956
...replacing it with the new, after passing API review!
* The lazy free function has become a property.
* Before we could extend protocols, we lacked a means for value types to
share implementations, and each new lazy algorithm had to be added to
each of up to four types: LazySequence, LazyForwardCollection,
LazyBidirectionalCollection, and LazyRandomAccessCollection. These
generic adapters hid the usual algorithms by defining their own
versions that returned new lazy generic adapters. Now users can extend
just one of two protocols to do the same thing: LazySequenceType or
LazyCollectionType.
* To avoid making the code duplication worse than it already was, the
generic adapters mentioned above were used to add the lazy generic
algorithms around simpler adapters such as MapSequence that just
provided the basic requirements of SequenceType by applying a
transformation to some base sequence, resulting in deeply nested
generic types as shown here. Now, MapSequence is an instance of
LazySequenceType (and is renamed LazyMapSequence), and thus transmits
laziness to its algorithms automatically.
* Documentation comments have been rewritten.
* The .array property was retired
* various renamings
* A bunch of Gyb files were retired.
Swift SVN r30902
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
The rule changes are as follows:
* All functions (introduced with the 'func' keyword) have argument
labels for arguments beyond the first, by default. Methods are no
longer special in this regard.
* The presence of a default argument no longer implies an argument
label.
The actual changes to the parser and printer are fairly simple; the
rest of the noise is updating the standard library, overlays, tests,
etc.
With the standard library, this change is intended to be API neutral:
I've added/removed #'s and _'s as appropriate to keep the user
interface the same. If we want to separately consider using argument
labels for more free functions now that the defaults in the language
have shifted, we can tackle that separately.
Fixes rdar://problem/17218256.
Swift SVN r27704
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
