In swift 1.2, `Slice` has been renamed `ArraySlice`.
In swift 2.0, type parameter name of `Array` is changed from `T` to `Element`.
Therefore, modified the names which appear in code comments and a document.
The new graphics reflects the current implementation of Array.
(I added the .graffle file long time ago, but it was never referenced from the rst file).
Swift SVN r31311
Squash _[Conditionally]BridgedToObjectiveC into one protocol. This
change results in simpler bridging code with fewer dynamic protocol
conformance checks, and solves the nasty naming/semantics problem that
resulted from having _ConditionallyBridgedToObjectiveC refining
_BridgedToObjectiveC.
Also, rename things so they're more symmetrical and less confusing.
Swift SVN r20664
Now that we use bridgeFromObjectiveCConditional to perform conditional
bridging, make bridgeFromObjectiveC handle forced bridging. For the
latter, deferred checking is acceptable.
Almost all of <rdar://problem/17319154>.
Swift SVN r19046
This change makes the story more coherent and consistent, and most
importantly, verifiable. I've pushed ContiguousArray and Slice out of
the bridge/cast picture in order to simplify the description of Array.
Writing the story for those other array types (someday) in terms of this
one should be straightforward.
Swift SVN r18229
I was previously reading this as, "if you don't have an ArrayBuffer<U>,
downcast fails in O(1)." We actually want it to fall through to
deferred in that case.
Swift SVN r18137
Trying to lazily compute bridge results and cache them isn't going to
work, because there's no place to efficiently invalidate the cache in
cases like this:
func f(a: NSArray) {
for i in 0...a.count {
println(a.objectAtIndex(i)) // Fills up the cache
}
}
var message = ["hello", "world"]
f(message)
message[0] = "goodbye, cruel" // need a cache invalidation or else
f(message) // ...this prints "hello\nworld\n"
Since we need C performance for subscript assignment, we just can't
afford to do anything extra there.
Instead, when the element type isn't "Bridged Verbatim," just eagerly
convert it to an NSArray.
Swift SVN r17722
We were wishfully thinking that we could convert all NSArrays lazily.
However, since non-class/existential types are supposed to have a
statically-knowable efficient representation we need an eager conversion
in those cases.
Swift SVN r17538
Chris suggested that we should lazily typecheck each element when an
NSArray is downcast to Array<T>. That sounded like a good idea, and
along the way we decided to simplify the implementation and spec by not
bending over backwards to allow broken duck-typing to work for pure ObjC
classes.
Swift SVN r17468
Chris suggested that we should lazily typecheck each element when an
NSArray is downcast to Array<T>. That sounded like a good idea, and
along the way we decided to simplify the implementation and spec by not
bending over backwards to allow broken duck-typing to work for pure ObjC
classes.
Swift SVN r17408
There's little point in allowing Array<T> to have both direct and
indirect representations when T can be a class type. Let's drop the
branch cost and generate less code.
Swift SVN r17353
There's no need to support up- or down-casts for NativeArray<T> or
Slice<T>. Slice might turn out to be easy, but we don't have time right
now. Doing it for NativeArray<T> would have efficiency costs that we
don't want to pay.
Swift SVN r17323
This is a partial update. We need to decide how to rework array
up-/down-casting to account for value semantics changes. Will post to
the list.
Swift SVN r17254
For now we're going to keep BridgedToObjectiveC as a private internal
implementation detail. Adding the "_" prefix marks it as internal.
Implements <rdar://problem/16736672>.
Swift SVN r16921
