With this, we're now using initializer requirements rather than
"convertFromXXX" requirements everywhere, addressing the rest of
rdar://problem/18154091. r22176 eliminated the performance penalty
that prevented this change from sticking earlier.
Swift SVN r22177
Calls to fromRaw are replaced with uses of the new failable
initializer init(rawValue:). Similarly, calls to toRaw are replaced
with uses of the rawValue property. Fixes rdar://problem/18357647.
Swift SVN r22164
The initializer requirement is causing too much exponential behavior
in the constraint solver. We'll have to address that
first. Re-instating this change is tracked by rdar://problem/18381811.
Swift SVN r22080
With this, we're now using initializer requirements rather than
"convertFromXXX" requirements everywhere, addressing the rest of
rdar://problem/18154091.
Swift SVN r22078
Conforming to BooleanLiteralConvertible now requires
init(booleanLiteral: Bool)
rather than
static func convertFromBooleanLiteral(value: Bool) -> Self
This posed a problem for NSNumber's conformance to
BooleanLiteralConvertible. A class needs a required initializer to
satisfy an initializer requirement, but one cannot add a required
initializer via an extension. To that end, we hack the Clang importer
to import NSNumber's initWithBool with the name
init(booleanLiteral:)
and add back the expected init(bool:) initializer in the
overlay. These tricks make NSNumber even harder to subclass, but we
don't really care: it's nearly impossible to do well anyway, and is
generally a Bad Idea.
Part of rdar://problem/18154091.
Swift SVN r21961
Per API review with Ali. While we're here, give the initializer a corresponding 'rawValue' argument label, and change the associated type name to RawValue to match.
Swift SVN r21888
Redefine the RawRepresentable protocol to use an 'init?' method instead of 'fromRaw(Raw)', and a 'raw' get-only property instead of 'toRaw()'. Update the compiler to support deriving conformances for enums and option sets with the new protocol. rdar://problem/18216832
Swift SVN r21762
This is useful both for caching purposes and for comparison of discriminators
(something the debugger will need to do when looking up a particular decl).
No observable functionality change.
Swift SVN r21610
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
This allows us to switch on an optional value and match it to concrete
values without explicitly writing the ".Some"'s. Better testing to follow...
Swift SVN r21018
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
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
To facilitate the removal of the BooleanType conformance from Optional<T>, we'll first need to support
equality comparisons between the 'nil' literal and optionals with non-equatable element types.
We can accomplish this via three changes:
- New overloads for "==" and "!=" that we can resolve against non-equatable optionals
- A tweak to our overload resolution algorithm that, when all other aspects of two overloads are
considered equal, would favor the overload with a more "constrained" type parameter. This allows
us to avoid ambiguities between generic overloads that are distinct, but whose parameters do not
share a pairwise subtype relationship.
- A gross hack to favor overloads that do not require bindings to 'nil' when presented with an
otherwise ambiguous set of solutions. (Essentially, in the face of a potential ambiguity, favor solutions
that do not require bindings to _OptionalNilComparisonType over those that do.)
The third change is only necessary because we currently lack the ability to specify "negative" or
otherwise more expressive constraints, so we'll want to rethink the hack post-1.0. (I've filed
rdar://problem/17769974 to cover its removal.)
Swift SVN r20346
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
This change pulls the handling of the element pattern and sequence of
a for-each loop into a single constraint system, so that we get type
inference between the two. Among other things, this allows one to
infer generic arguments within the element pattern from the sequence's
element type as well as allowing type annotations or the form of the
element pattern to affect overload resolution and generic argument
deduction for the sequence itself.
Swift SVN r19721
Previously, bridged value types and their corresponding Objective-C
classes allow inter-conversion via a number of user-defined conversion
functions in the Foundation module. Instead, make this a general
feature of the type checker so we can reason about it more
directly. Fixes <rdar://problem/16956098> and
<rdar://problem/17134986>, and eliminates 11 (half) of the
__conversion functions from the standard library and overlays.
A few notes:
- The XCTest changes are because a String can no longer directly
conform to CVarArg: this is a Good Thing (TM), because it should be
ambiguous: did you mean to pass it as an NSString or a C string?
- The Objective-C representations for the bridged collections are
hard-coded in the type checker. This is unfortunate and can be
remedied by adding another associated type to the
_BridgedToObjectiveC protocol.
Swift SVN r19618
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
This makes categories of NSString, NSArray, and NSDictionary available
on String, Array, and Dictionary. Note that we only consider
categories not present in the Objective-C Foundation module, because
we want to manually map those APIs ourselves. Hence, no changes to the
NSStringAPI. Implements <rdar://problem/13653329>.
Swift SVN r18920
This is all goodness, and eliminates a major source of implicit conversions.
One thing this regresses on though, is that we now reject "x == nil" where
x is an option type and the element of the optional is not Equtatable. If
this is important, there are ways to enable this, but directly testing it as
a logic value is more straight-forward.
This does not include support for pattern matching against nil, that will be
a follow on patch.
Swift SVN r18918
Allow class metatypes (including class-constrained existential metatypes) to be treated as subtypes of AnyObject, and single-@objc protocol metatypes to be treated as subtypes of the Protocol class from objc. No codegen support yet, so this is hidden behind a frontend flag for now.
Swift SVN r18810
We were failing to recognize '.Protocol' as a postfix type expression everywhere we needed to, and we were resolving neither 'T.Type' or 'T.Protocol' to a type reference in expression context.
Swift SVN r18789
String interpolation invokes convertFromStringInterpolationSegment() function
now. There is no need to add extensions to String to allow custom types to
participate in string interpolation. Just implementing Printable will do the
right thing.
Swift SVN r18104
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
Formatting names into strings repeatedly, and using those for semantic
analysis, is generally considered poor form. Additionally, use the
camelCase utilities to perform the string manipulation we need, and
cache results on the ObjCAttr so we don't repeatedly do string
manipulation.
Swift SVN r16334
This significantly reduces the amount of overhead incurred when naively importing large external modules without referencing many of its members, which should directly improve response times in the playground. For example, the repro code attached to rdar://problem/16387393 imports Foundation but references none of its members, and with these changes its total compilation time is almost 2.5x faster.
Swift SVN r15479
Take DynamicSelf as a keyword, but parse it as a type-identifier.
Teach function declaration checking to sniff out and validate
DynamicSelf early, with appropriate QoI for references to DynamicSelf
that appear in other places.
As a temporary hack, DynamicSelf resolves to an alias for 'Self' in a
protocol or the enclosing nominal type.
Swift SVN r12708
