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
When a non-final class satisfies a method requirement that returns
Self, it must do so with a method that also returns (dynamic)
Self. This ensures conformance will be inheritable, closing off an
awful type-safety hole <rdar://problem/16880016>. Other
non-contravariant uses of Self in the signatures of requirements cause
the protocol to be unusable by non-final classes.
I had to leave a tiny little gaping hole for the ~> operator, whose
removal is covered by <rdar://problem/17828741>. We can possibly put
this on firm footing with clever handling of generic witnesses, but
it's not important right now.
Swift SVN r20626
It seems not-great that the same candidate can get into the overload set for a DeclRefExpr
multiple times, but if it does, don't expose this to the user.
Swift SVN r20315
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
eliminating the @'s from them when used on func's. This is progress towards
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
This also consolidates rejection of custom operator definitions into one
place and makes it consistent, and adds postfix "?" to the list of rejected
operators.
This also changes the demangler to demangle weak/inout/postfix and related things
without the @.
Swift SVN r19929
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
JoeP helped tweak things to ensure that pointer conversions are still
considered, but we no longer need the disjunction on InOutExprs to accommodate
user-defined inout conversions.
This causes some regressions in error reporting:
<rdar://problem/17489983> inout type mismatches complain about '@lvalue inout T'
<rdar://problem/17489894> inout not rejected as operand to assignment operator
Swift SVN r19306
We haven't been advertising this syntax much, and it's closure form
was completely broken anyway, so don't jump through hoops to provide
great Fix-Its here.
Swift SVN r19277
Better to describe how the protocol can be used than how it can't. Also include a mention of Self type requirements as a source of non-existentiability.
Swift SVN r19207
This is motivated by <rdar://problem/17051606>.
This ends up renaming variables as well, which seems right for
consistency since we use "predicate" as variable name.
Swift SVN r19135
Add primitive type-checker rules for pointer arguments. An UnsafePointer argument accepts:
- an UnsafePointer value of matching element type, or of any type if the argument is UnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is UnsafePointer<Void>, or
- an inout Array parameter of matching element type, or of any type if the argument is UnsafePointer<Void>.
A ConstUnsafePointer argument accepts:
- an UnsafePointer, ConstUnsafePointer, or AutoreleasingUnsafePointer value of matching element type, or of any type if the argument is ConstUnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>, or
- an inout or non-inout Array parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>.
An AutoreleasingUnsafePointer argument accepts:
- an AutoreleasingUnsafePointer value of matching element type, or
- an inout parameter of matching element type.
This disrupts some error messages in unrelated tests, which is tracked by <rdar://problem/17380520>.
Swift SVN r19008
These types are often useless and confusing to users who expect to be able to use Sequence or Generator as types in their own right like in C# or Java. While we're here, relax the rules for self-conformance to admit methods returning 'Self'. Covariant return types should not actually prevent a protocol type from conforming to itself, and the stdlib makes particular use of protocols with 'init' requirements which implicitly return Self.
Swift SVN r18989
One difficulty in generating reasonable diagnostic data for type check failures has been the fact that many constraints had been synthesized without regard for where they were rooted in the program source. The result of this was that even though we would store failure information for specific constraints, we wouldn't emit it for lack of a source location. By making location data a non-optional component of constraints, we can begin diagnosing type check errors closer to their point of failure.
Swift SVN r18751
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
The old ones were:
- print/println
- printAny
- printf
- Console
The new printing story is just print/println. Every object can be printed.
You can customize the way it is printed by adopting Printable protocol. Full
details in comments inside stdlib/core/OutputStream.swift.
Printing is not completely finished yet. We still have ReplPrintable, which
should be removed, string interpolation still uses String constructors, and
printing objects that don't conform to Printable will result in printing
mangled names.
Swift SVN r18001
(These changes also address the type-check aspects of rdar://problem/16369105, but there are still some SIL generation issues that I need to work through before I can call that work done.)
Swift SVN r15337
When a specialization of a generic type occurs within the signature of
a generic function, it implies that the generic arguments meet the
requirements of the generic type. For example, in
func printHashes<K, V>(dict : Dictionary<K, V>) {
for (k, v) in dict {
print("\(k.hashValue())\n")
}
}
the presence of Dictionary<K, V> in the signature implies that K and V
meet the requirements on Dictionary's generic parameters, i.e., that K
is Hashable. Thus, infer that K is Hashable in printHashes().
Fixes the easy part of <rdar://problem/14691708>. Same-type and
superclass requirements are more interesting.
<rdar://problem/14691708>
Swift SVN r7574
When checking a type's conformance against a protocol, we can deduce
the values of associated types. Make these associated types visible to
qualified name lookup so that (for example) VectorEnumeratorType does
not need to define the Element type. It is deduced from the signautre
of next(), and made available as, e.g.,
VectorEnumeratorType<Int>.Element through the Enumerator protocol
conformance. Fixes <rdar://problem/11510701>, but with some lingering
dependencies on lazy type resolution (<rdar://problem/12202655>).
Note that the infrastructure here is meant to be generalized to
support default implementations in protocols, but there are several
pieces still not in place.
Swift SVN r6073
This change enables inheritance constraints such as "T : NSObject",
which specifies that the type parameter T must inherit (directly or
indirectly) from NSObject. One can then implicit convert from T to
NSObject and perform (checked) downcasts from an NSObject to a T. With
this, we can type-
IR generation still needs to be updated to handle these implicit
conversions and downcasts. New AST nodes may follow.
Swift SVN r3459
Add a couple other misc pieces necessary for semantic analysis of members of
generic types. We're now up to the point where we can actually construct a
useful AST for small testcases.
Swift SVN r2308
coercion. Overload resolution uses this argument deduction when
dealing with generic functions, to determine when we can invoke a
generic function. When a generic function is selected, we create a
SpecializeExpr wrapping the DeclRefExpr to the generic function.
This is sufficient to type-check calls to simple things like a call to
func identity<T>(x : T) -> T { return x }
with a value of known type. However, it's missing far too many pieces
to enumerate.
Swift SVN r2230
functions. This involves a few steps:
- When assigning archetypes to type parameters, also walk all of the
protocols to which the type parameter conforms and assign archetypes
to each of the associated types.
- When performing name lookup into an archetype, look into all of
the protocols to which it conforms. If we find something, it can be
referenced via the new ArchetypeMemberRefExpr.
- When type-checking ArchetypeMemberRefExpr, substitute the values
of the various associated types into the type of the member, so the
resulting expression involves the archetypes for the enclosing
generic method.
The rest of the type checking essentially follows from the fact that
archetypes are unique types which (therefore) have no behavior beyond
what is provided via the protocols they conform to. However, there is
still much work to do to ensure that we get the archetypes set up
correctly.
Swift SVN r2201
introduce the generic type parameters (which are simply type aliases
for a to-be-determined archetype type) into scope for name
lookup. We can now parse something like
func f<T, U : Range>(x : T, y : U) { }
but there is no semantic analysis or even basic safety checking (yet).
Swift SVN r2197
