To limit user confusion when using conditional expressions of type Bool?, we've decided to remove the BooleanType (aka "LogicValue") conformance from optional types. (If users would like to use an expression of type Bool? as a conditional, they'll need to check against nil.)
Note: This change effectively regresses the "case is" pattern over types, since it currently demands a BooleanType conformance. I've filed rdar://problem/17791533 to track reinstating it if necessary.
Swift SVN r20637
|=, &=, and ^= now come along for free with a BitwiseOperationsType
conformance, so we can remove the special-cased operators for
RawOptionSetType.
Also, release notes.
Swift SVN r20630
When a non-final class satisfies a method requirement that returns
Self, it must do so with a method that also returns (dynamic)
Self. This ensures conformance will be inheritable, closing off an
awful type-safety hole <rdar://problem/16880016>. Other
non-contravariant uses of Self in the signatures of requirements cause
the protocol to be unusable by non-final classes.
I had to leave a tiny little gaping hole for the ~> operator, whose
removal is covered by <rdar://problem/17828741>. We can possibly put
this on firm footing with clever handling of generic witnesses, but
it's not important right now.
Swift SVN r20626
In answering a forum post I noiced that I wanted this and it was
missing.
Also, extensive comments
Also, rename the length: init parameter to count:. When writing the
comments for the init function it became painfully clear why we use
"count" is better than "length" especially around pointers and memory:
the former is much less easy to mistake for "length in bytes". Plus
it's consistent with the new ".count" property
Swift SVN r20609
Similar to nil-coalescing operators in other languages, this operator takes an optional on the left and a non-optional expression on the right, and if the optional is nil, evaluates the right side, otherwise returning the value from the optional itself. <rdar://problem/15247356>
Swift SVN r20593
When an integer type T is used as an Index, there are always
bounds---more restrictive than the full range of T---against which we're
not able to check. Overflows are not useful indicators of precondition
violations in this context. Therefore, use masked arithmetic for
RandomAccessIndex conformance.
Performance changes of magnitude >= 5% are below. Someone might want to
investigate why Fibonacci got 21% faster in -Ounchecked, since nothing
in this change should have removed checks from that build. (That test
does seem particularly sensitive; see also <rdar://problem/17815767>
Adding three overloads to stdlib slows Fibonacci by 18-19%)
Fixes <rdar://problem/17780469> Integer ranges shouldn't use overflowing adds
====================`PrecommitBench_O`====================
````benchmark`|`baserun0`|`baserun1`|`optrun0`|`optrun1`|``delta`|`speedup`
````Ackermann`|``1428.00`|``1466.00`|`1661.00`|`1657.00`|`229.00`|``-13.8%`
`````ForLoops`|``2021.00`|``1986.00`|`1249.00`|`1255.00`|`737.00`|```59.0%`
`````````Hash`|``1038.00`|```979.00`|``898.00`|``922.00`|``81.00`|````9.0%`
`````````Life`|````63.00`|````63.00`|```60.00`|```61.00`|```3.00`|````5.0%`
```````Memset`|````55.00`|````54.00`|```42.00`|```42.00`|``12.00`|```28.6%`
``MonteCarloE`|``1243.00`|``1265.00`|``885.00`|``880.00`|`363.00`|```41.3%`
`MonteCarloPi`|```994.00`|``1004.00`|``613.00`|``605.00`|`389.00`|```64.3%`
````````NBody`|````45.00`|````45.00`|```42.00`|```43.00`|```3.00`|````7.1%`
````QuickSort`|```105.00`|```103.00`|```83.00`|```83.00`|``20.00`|```24.1%`
````R17315246`|``1080.00`|``1080.00`|``805.00`|``808.00`|`275.00`|```34.2%`
``````SmallPT`|``1008.00`|``1007.00`|``789.00`|``795.00`|`218.00`|```27.6%`
````````Walsh`|```136.00`|```136.00`|``129.00`|``130.00`|```7.00`|````5.4%`
====================`PrecommitBench_Ounchecked`====================
````benchmark`|`baserun0`|`baserun1`|`optrun0`|`optrun1`|``delta`|`speedup`
``Dictionary3`|``1060.00`|``1039.00`|``982.00`|`1029.00`|``57.00`|````5.8%`
````Fibonacci`|```842.00`|```848.00`|``694.00`|``694.00`|`148.00`|```21.3%`
```StringWalk`|```945.00`|```924.00`|``989.00`|``995.00`|``65.00`|```-6.6%`
====================`PrecommitBench_Onone`====================
````benchmark`|`baserun0`|`baserun1`|`optrun0`|`optrun1`|``delta`|`speedup`
`EditDistance`|``2086.00`|``1981.00`|`1492.00`|`1622.00`|`489.00`|```32.8%`
`````````Life`|``1256.00`|``1216.00`|`1110.00`|`1142.00`|`106.00`|````9.5%`
```````MatMul`|``1210.00`|``1245.00`|``705.00`|``705.00`|`505.00`|```71.6%`
````R17315246`|```205.00`|```209.00`|``195.00`|``200.00`|``10.00`|````5.1%`
Swift SVN r20576
Fixes <rdar://problem/17797711>
This is rather a kluge because of two other problems. Having these
fixed would allow a cleaner solution:
<rdar://problem/17815538> synthesize an allZeros static var for
BitwiseOperationsType conformance of imported NS_OPTIONS
<rdar://problem/17815767> Adding three overloads to stdlib slows
Fibonacci by 18-19%
Swift SVN r20563
to emit fixit's when we rename something, e.g.:
t.swift:6:9: error: 'float' has been renamed to Float
var y : float
^~~~~
Float
Adopt this in the stdlib.
Swift SVN r20549
is performed according to the deterministic Unicode collation algorithm,
which allows us to use the hash of the NFD form.
rdar://17498444
Swift SVN r20543
unexpected forematter from the superclass.
This requires a pretty substantial shift in the
generic-metadata allocation/initialization dance
because (1) we can't allocate class metadata without
knowing what the superclass is and (2) the offset
from the metadata cache entry to the address point is
no longer determined solely by the metadata pattern.
While I'm making invasive changes to metadata, fix
two race conditions in metadata creation. The first
is that we need to ensure that only one thread succeeds
at lazily creating a generic-metadata cache. The second
is that we need to ensure that only one thread actually
attempts to create a particular metadata; any others
should block until the metadata is successfully built.
This commit finishes rdar://17776354. LLDB will
need to adjust to the runtime-private metadata layout
changes.
Swift SVN r20537
normalization
There is still some obscure bug with != on NSString, probably caused by
an ill-thought overload somewhere.
Part of rdar://17498444
Swift SVN r20518
This was added for benchmarking purposes, without the realization that
it conflicts with the NSString API we adopt when importing Foundation.
http://oleb.net/blog/2014/07/swift-strings/#comparing-strings describes
the problem.
Fixes <rdar://problem/17800504>
Swift SVN r20517
