Use protocol conformance checks whenever we want to determine whether
a value type is bridged to an Objective-C class, which is simpler and
more robust. Clean up some of the type checker code around bridging,
using TypeBase::isEqual() to compare types and looking through type
sugar more regularly.
As part of this, move Array's conformance to
_ConditionallyBridgedToObjectiveC into the Foundation overlay. This
lets us use NSArray as the bridged type (which is clearer than using
CocoaArray), and follows what we're doing for dictionary bridging.
As part of this, move Array's bridged-to-
Swift SVN r17868
We now allow bridging so long as both K and V can be bridged to
Objective-C, as determined by _BridgedToObjectiveC conformance. Note
that Dictionary's implementation still needs to handle this, which is
tracked separately.
Swift SVN r17859
double-quoted string literals that contain a single extended grapheme cluster
SEGCL by default infer type String, but you can ask to infer Character
for them.
Single quoted literals continue to infer Character.
Actual extended grapheme cluster segmentation is not implemented yet,
<rdar://problem/16755123> Implement extended grapheme cluster
segmentation in libSwiftBasic
This is part of
<rdar://problem/16363872> Remove single quoted characters
Swift SVN r17034
We'll need types to be convertible from multiple kinds of inouts, which currently can't be represented with protocol conformance since we only allow one protocol conformance per type per protocol. Instead just look for a magic "__inout_conversion" static method in the type; this is lame but easy, and inout conversions shouldn't be available outside of the stdlib anyway.
Swift SVN r15599
The name Stream didn't seem to be working out as intended; we kept
gravitating back to calling it Generator, which is precedented in other
languages. Also, Stream seems to beg for qualification as Input or
Output. I think we'd like to reserve Stream for things that are more
bulk-character-API-ish.
Swift SVN r13893
Make the compiler fully support both UTF-8 and UTF-16 string
literals. A (standard-library-defined) string type (such as String)
that wants UTF-16 string literals should conform to the
BuiltinUTF16StringLiteralConvertible protocol; one that wants UTF-8
string literals should conform to the BuiltinStringLiteralConvertible
protocol.
Note that BuiltinUTF16StringLiteralConvertible inherits from
BuiltinStringLiteralConvertible, so a string type that wants UTF-16
string literals also has to implement support for UTF-8. The UTF-16
entry point is preferred when the compiler knows that UTF-16 is
supported. This only tends to happen when we have a generic parameter
that is required to conform to StringLiteralConvertible, e.g.,
func f<T: StringLiteralConvertible>() {
var t: T = "Hello, World!" // uses UTF-8 entry point
}
because the UTF-8 entry point is the only one guaranteed to be available.
Swift SVN r12014
This is step 1 of implementing the new Container/Sequence/Stream
protocols. See test/Prototypes/Container.swift for the complete picture
of where this is headed.
Swift SVN r11924
When performing member lookup into an existential that involves the
DynamicLookup protocol, look into all classes and protocols for that
member. References to anything found via this lookup mechanism are
returned as instances of Optional.
This introduces the basic lookup mechanics into the type
checker. There are still numerous issues to work through:
- Subscripting isn't supported yet
- There's no SILGen or IRGen support
- The ASTs probably aren't good enough for the above anyway
- References to generics will be broken
- Ambiguity resolution or non-resolution
Thanks to Jordan for the patch wiring up DynamicLookup.
Swift SVN r7689
This doesn't do anything yet, but will be used to record which decls
conform to these protocols when serializing a module.
This introduces a new metaprogramming file, KnownProtocols.def.
Swift SVN r7263
