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
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
Array literal construction currently goes through an expensive dance;
Adding _allocateUninitialized will allow SILGen to do something much
smarter.
Swift SVN r20448
This way, array optimization can see initialization as a copy of the
whole array value into a local variable, regardless of whether it's
from a factory method or Array initializer.
I'm making an assumption that when we return an Array by value, we
can't have an alias of the array buffer without retaining it.
Swift SVN r20444
Ultimately this gets to HeapBuffer which checks the index is in range by separately checking whether the storage is nil, then the index is less than the count
Swift SVN r20363
Lift the precondition that contiguous storage already exist on the use
of Array.withUnsafe[Mutable]PointerToElements. Automatically guarantee
that storage is unique when using the mutable variants of these methods.
Also, fix some---essentially---inout aliasing violations in
test/stdlib/Unicode.swift that were revealed by the new careful
implementation of these methods.
Swift SVN r20339
The global first() and last() algorithms return T?, nil when empty
All .first() and .last() methods became T? vars that are nil when the
Collection is empty
Swift SVN r20326
Arrays of non-verbatim-bridged types (such as Int, and today's String)
are converted to Objective-C lazily, with the objects created due to
element conversion being autoreleased when necessary.
Fixes <rdar://problem/17360154>
Note: test/SIL/Parser/array_roundtrip.swift was XFAIL'd;
see <rdar://problem/17758203>
Swift SVN r20293
+= only extends arrays with another sequence of the same element type.
Fixes <rdar://problem/17151420> The use of the overloaded += operator in
Swift is inconsistent and confusing with Arrays.
Note that this commits generated 3 new radars against the type checker:
<rdar://problem/17751308>
<rdar://problem/17750582>
<rdar://problem/17751359>
Swift SVN r20274
We've decided resilience is wrong for Swift given current constraints;
see rdar://problem/11940897 for more detail.
This reverts commit r20052
Swift SVN r20127
enforce its own little constraints. The type checker isn't using it for
anything, and it is just clutter.
This resolves <rdar://problem/16656024> Remove @assignment from operator implementations
Swift SVN r19960
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
ArrayBuffer
ArrayBufferType
ContiguousArrayBuffer
ContiguousArrayStorage
IndirectArrayBuffer
SliceBuffer
Unfortunately, can not remove 'public' from them since they are used by
Foundation overlay in bridging code.
Swift SVN r19810
When a user violates the inout rules by "re-entering" an array that is
currently undergoing mutation, it must not admit a memory-safety
violation. To ensure that it doesn't, temporarily make the buffer being
operated on inaccessible through the original array.
Swift SVN r19532
This does not yet handle variables with inferred types, since those don't
have TypePatterns.
There is some nasty propagation of @public into the stdlib because of this
one, mainly because Foundation needs access to some of the implementation
details of Array and Dictionary. We may want to try to improve this later
(or just build Foundation with -disable-access-control if it comes to that).
Swift SVN r19432
...unless the type has less accessibility than the protocol, in which case
they must be as accessible as the type.
This restriction applies even with access control checking disabled, but
shouldn't affect any decls not already marked with access control modifiers.
Swift SVN r19382
- Follow LLVM conventions for emacs mode specification
- Use local variables suffix to make the output read-only (at least on
Emacs)
- But drop the admonitions not to edit the generated files;
line-directive mostly takes care of that problem now.
Swift SVN r19381
As before, there may be more things marked @public than we actually want
public. Judicious use of the frontend option -disable-access-control may
help reduce the public surface area of the stdlib.
Swift SVN r19353
This one shows the unfortunate consequence that we need
Lazy[Forward|Bidirectional|RandomAccess]Collection. There's gonna be a
whole lotta gyb'bing going on...
Swift SVN r19316
This API exposes unmediated access to memory, and most users will never
see the UnsafeArray argument that's passed to the closure, so best to be
explicit.
Swift SVN r19243
Until we get an optimizer pass to remove get/set pairs, passing a
property that is a protocol requirement as inout from generic code is
always going to cause an extra retain, causing many unintended Array
copies.
Because this dropped reference counts to 1 in some cases, it exercised
previously-untested code paths and uncovered bugs, particularly in the
handling of subrange replacement on Slice<T>.
There are still differences in speed for short arrays of CGPoint that bear
investigation, but at least as things scale up, the ratio of time goes
to 1.
Fixes <rdar://problem/17040913> append and += on an array have
completely different performance
Swift SVN r19228
