One last bit of SE-0072. We shouldn't fall back to bridged classes in the absence of type context for literals anymore. By itself, this kind of hoses the use of literals with NS types, but I think we can get most of the QoI back with overlay changes I plan to propose following this.
This is a squash of the following commits:
* [SE-0054] Import function pointer arg, return types, typedefs as optional
IUOs are only allowed on function decl arguments and return types, so
don't import typedefs or function pointer args or return types as IUO.
* [SE-0054] Only allow IUOs in function arg and result type.
When validating a TypeRepr, raise a diagnostic if an IUO is found
anywhere other thn the top level or as a function parameter or return
tpye.
* [SE-0054] Disable inference of IUOs by default
When considering a constraint of the form '$T1 is convertible to T!',
generate potential bindings 'T' and 'T?' for $T1, but not 'T!'. This
prevents variables without explicit type information from ending up with
IUO type. It also prevents implicit instantiation of functions and types
with IUO type arguments.
* [SE-0054] Remove the -disable-infer-iuos flag.
* Add nonnull annotations to ObjectiveCTests.h in benchmark suite.
And they're not even guaranteed to be casts to ObjC classes. They might be
Swift subclasses of ObjC classes.
This fixes a type-safety hole where, e.g. a generic cast from NSPredicate
to NSDate was allowed because we were checking against NSObject.
rdar://problem/22242369
Swift SVN r31153
Require 'as' when converting from Objective-C type to native type (but
continue to allow implicit conversion from native to Objective-C). This
conversion constraint is called ExplicitConversion; all implicit
conversions are covered by the existing Conversion constraint. Update
standard library and tests to match.
Swift SVN r24496
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
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
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
Previously, we were unable to handle bridged downcasts to optional
types from optional sources, because because we applied the bridging
operation after we had already evaluated all of the bound optionals
(causing a crash). Now, we perform the bridging immediately after the
underlying forced or conditional cast, before evaluating the outer
bound optionals.
This also eliminates a bunch of code duplication between the forced
and conditional downcasts, now that the bridging code is shared.
Swift SVN r19065
This entry point is used in conditional downcasts (as?) to attempt to
bridge from an Objective-C class down to a specific native type (e.g.,
array, dictionary), bridging all elements eagerly so that it can
produce nil if the bridging would fail.
This is the scaffolding for <rdar://problem/17319154>, and makes the
example there work, but there is much more cleanup and optimization to
do.
Swift SVN r18999
Previously, we were only changing whether the object was of the right
type, and not performing a deep check that (for example) the
underlying array contained NSStrings for an "is String[]". Fixes the
rest of <rdar://problem/16972956>.
Swift SVN r18728
Rather than only allowing downcasting from AnyObject, allow it for any
class or Objective-C existential type, e.g., "NSArray() as
Int[]". While here, reduce our reliance on implicit conversions when
checking bridging. This is most of <rdar://problem/16972956>, but 'is'
still doesn't work properly in these cases.
Swift SVN r18693
There's a bit of a reshuffle of the ExplicitCastExpr subclasses:
- The existing ConditionalCheckedCastExpr expression node now represents
"as?".
- A new ForcedCheckedCastExpr node represents "as" when it is a
downcast.
- CoerceExpr represents "as" when it is a coercion.
- A new UnresolvedCheckedCastExpr node describes "as" before it has
been type-checked down to ForcedCheckedCastExpr or CoerceExpr. This
wasn't a strictly necessary change, but it helps us detangle what's
going on.
There are a few new diagnostics to help users avoid getting bitten by
as/as? mistakes:
- Custom errors when a forced downcast (as) is used as the operand
of postfix '!' or '?', with Fix-Its to remove the '!' or make the
downcast conditional (with as?), respectively.
- A warning when a forced downcast is injected into an optional,
with a suggestion to use a conditional downcast.
- A new error when the postfix '!' is used for a contextual
downcast, with a Fix-It to replace it with "as T" with the
contextual type T.
Lots of test updates, none of which felt like regressions. The new
tests are in test/expr/cast/optionals.swift.
Addresses <rdar://problem/17000058>
Swift SVN r18556
Previously, we were relying on user-defined conversions to perform the
final bridging from the Objective-C class type (e.g., NSString) to its
Swift value type (String). That works for NSString <-> String, but not
for arbitrary arrays. Use the bridgeFromObjectiveC() witness instead,
so we can handle:
let obj: AnyObject = ...
let strArr: String[] = obj!
Fixes <rdar://problem/16952771>.
Swift SVN r18422
This makes fun bridging like
var obj: AnyObject! = [3.14159, 2.71828, 0] as Double[]
if let intArr = obj as Int[] {
println("Array of doubles as ints is \(intArr)")
}
"work", given that NSNumber is the common class type through which we
are bridging.
Swift SVN r18398
This allows us to cast an AnyObject (or optional thereof) down to a
specific array, e.g.,
if let strArr = obj as String[] { ... }
Addresses most of <rdar://problem/16952771>.
Swift SVN r18397
The "is" expression itself isn't really able to cope with optionals
well itself, so in the hard cases we'll defer to a conditional checked
cast and then check whether the resulting optional is non-empty. Fixes
the rest of <rdar://problem/16953860>.
Swift SVN r18361
Checked casting handles multiple levels of optionality properly
already, and does so by binding rather than forcing. Fixes the
immediate issue in <rdar://problem/16953860>.
Swift SVN r18351
This allows us to cast "through" a bridged class type in an "as" case,
e.g.,
if let str = obj as String { ... }
where obj is an AnyObject (or optional/implicitly unwrapped optional
thereof). In such cases, we perform a checked cast to the
corresponding class type (NSString in this case) and then convert the
(optional!) result down to the value type.
Addresses the main part of <rdar://problem/15288553>, but we still
have trouble with "is" with optionals, and the #if false'd out
testcase incorrectly fails due to <rdar://problem/16953860>.
Swift SVN r18347
This fixes a case where the Swift-variadic and C-varargs versions of
various initializers were superseding each other
<rdar://problem/16801456>.
It also uncovered some more cases where we weren't getting quite the
right semantics for factory-methods-as-initializers, which are also
fixed here.
Swift SVN r18010
