The name may have the wrong implication to a C++'er, but the point is
that this Collection is a Lazy version of the map() function. Maybe we
should be giving our Collections capitalized lazy versions of their
member algorithms, e.g.
a.Map {something}
Swift SVN r16110
Array's getObjects:range: needs to fill the supplied buffer without
incrementing the reference count. For that reason, and to fulfill
lifetime expectations for Array elements that are computed
dynamically (e.g. from value types that are BridgedToObjectiveC), we
maintain a cache of converted objects associated with each Array.
Swift SVN r16105
Just moving things between files, and creating a few new source files, in
the standard library, so it's easier to find a given component.
Swift SVN r16094
Make these three types conform to the BridgedToObjectiveC
protocol, which is needed for array bridging. This is one part of
<rdar://problem/16533359>.
Because this must happen in the Foundation module, hack
swift_conformsToProtocol to look in the Foundation module for
conformances when it can't find them in the module corresponding to
the type. This is an egregious hack to an egregious hack, but it gets
us closer.
Swift SVN r15997
Adds an overlay for Xcode's XCTest testing framework.
It implements most of the familiar test assertion macros as equivalent
Swift functions. The assertion macros that aren't currently implemented
are only those that deal specifically with floating-point equality and
Objective-C exceptions. Additionally, the implemented assertions don't
currently handle Objective-C exceptions thrown out of some code called
during an assertion as test failures.
Swift SVN r15917
These are both past mistakes from me. One is a case of me missing the
OBJCPTR macro (which adds the UncheckedOptional bit); the other is a case
of including it when the block is actually written in Swift (and thus uses
a non-optional string).
<rdar://problem/16519094&16513659>
Swift SVN r15915
ObjC pointer types as UncheckedOptional.
Some of these changes are totally necessary; others may
simply reflect language/implementation work that hasn't
been done yet.
If anything seems particularly objectionable, bugs welcome.
Swift SVN r15783
Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
All of the malloc zone APIs are clumsy object-oriented design in C, but that
does not mean we should be too. This should clarify the design more too.
Swift SVN r15690
The ArrayType protocol is developed for NewArray is a good basis for
what we want, but the ability to create arrays without value semantics
is adding complexity but questionable value. It isn't clear that we can
usefully expose a type called SharedArray<T>, even internally, if it
ceases to be truly shared when one copy grows, and therefore has its
buffer reallocated. Therefore, leave the NewArray test with a
ArrayType2, a refinement of ArrayType, that adds the ability to report
on its value semantics.
If we really want the optimizations that can be had in a large-scale
mutation by first unique'ing the array and making mutations in-place
thereafter, we can fall back to operating on NativeArrayBuffer<T>
directly.
Swift SVN r15673
