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
Also, hide an initializer on String.Index that was unintentionally
public/visible by giving it an underscored keyword argument.
Testing comes next.
Swift SVN r24069
The syntax being reverted added busywork and noise to the common case
where you want to say "I have the right address, but the wrong type,"
without adding any real safety.
Also it eliminated the ability to write UnsafePointer<T>(otherPointer),
without adding ".self" to T. Overall, it was not a win.
This reverts commits r21324 and r21342
Swift SVN r21424
Depending on visitation order, we would occasionally leave the factory
method available if we had completely imported the initializer
first. Fixes <rdar://problem/17261609>.
Swift SVN r21361
Previously, it was possible to write Unsafe[Mutable]Pointer(x) and have
Swift deduce the pointee type based on context. Since reinterpreting
memory is a fundamentally type-unsafe operation, it's better to be
explicit about conversions from Unsafe[Mutable]Pointer<T> to
Unsafe[Mutable]Pointer<U>. This change is consistent with the move from
reinterpretCast(x) to unsafeBitCast(x, T.self).
Also, we've encoded the operations of explicitly adding or removing
mutability as properties, so that adding mutability can be separated
from wild reinterpretCast'ing, a much more severe form of unsafety.
Swift SVN r21324
stringByAddingPercentEncodingWithAllowedCharacters() and
stringByAddingPercentEscapesUsingEncoding() to String?, and add API notes for
NSString to the same effect
Swift SVN r21007
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
The length could already be given by the input sequence. Also, make it
accept any generic Sequence of bytes, rather than requiring an array.
Fixes <rdar://problem/17034413>
Swift SVN r20480
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
Introduce the new BooleanLiteralConvertible protocol for Boolean
literals. Take "true" and "false" as real keywords (which is most of the
reason for the testsuite churn). Make Bool BooleanLiteralConvertible
and the default Boolean literal type, and ObjCBool
BooleanLiteralConvertible. Fixes <rdar://problem/17405310> and the
recent regression that made ObjCBool not work with true/false.
Swift SVN r19728
There's a regression here because we can no longer use "true" or
"false" with ObjCBool. We'll get that back when true and false become
literals.
Swift SVN r19694
There is some follow-up work remaining:
- test/stdlib/UnicodeTrie test kills the type checker without manual type annotations. <rdar://problem/17539704>
- test/Sema/availability test raises a type error on 'a: String == nil', which we want, but probably not as a side effect of string-to-pointer conversions. I'll fix this next.
Swift SVN r19477
Keep calm: remember that the standard library has many more public exports
than the average target, and that this contains ALL of them at once.
I also deliberately tried to tag nearly every top-level decl, even if that
was just to explicitly mark things @internal, to make sure I didn't miss
something.
This does export more than we might want to, mostly for protocol conformance
reasons, along with our simple-but-limiting typealias rule. I tried to also
mark things private where possible, but it's really going to be up to the
standard library owners to get this right. This is also only validated
against top-level access control; I haven't fully tested against member-level
access control yet, and none of our semantic restrictions are in place.
Along the way I also noticed bits of stdlib cruft; to keep this patch
understandable, I didn't change any of them.
Swift SVN r19145
rangeOfCharacterFromSet(_:options:range:)
The underlying Objective-C API could return an NSRange of NSNotFound. Swift's
String.Index can not represent that, so change the API to return an optional
Swift Range<Index> instead.
Swift SVN r18679
stringWithBytes(_:length:encoding:) was passing an array to Objective-C
incorrectly, and a garbage NSString was being constructed as a result.
Unhide the initializer was accidentally hidden.
Swift SVN r18674
