The implementation-detail requirement Error._userInfo is always an
NSDictionary?. However, because this requirement is declared within
the standard library, it cannot be typed as such. So, use
'AnyObject?', comment that this is always 'NSDictionary?' in practice,
and fix up the uses.
Addresses rdar://problem/27824194 as much as we can.
Rather than having Sema provide a default implementation of
Error._code when needed, introduce a runtime function to extract the
default code, so that we can provide a default implementation via a
protocol extension in the standard library.
This reverts commit dc0ae675bc. The
change here (presumably the change to Foundation) caused a regression
in several of the bridging-related benchmarks, e.g.,
ObjectiveCBridgeFromNSSetAnyObjectToString, DictionaryBridge,
ObjectiveCBridgeFromNSDictionaryAnyObjectToString.
Remove the functions
_(set|dictionary)Bridge(From|To)ObjectiveC(Conditional) from the
standard library. These entrypoints are no longer used by the compiler
(thanks to generalized collection up/downcasting), so stop using them
in Foundation and in tests.
instead of forcing conditional casts of the elements.
This should produce better and more compact code, allow more
efficient runtime behavior, and generate much better runtime
diagnostics if the cast fails.
We want to be robust against unexpected `nil`s when bringing `id`s into Swift as `Any`. Add a function that builds an AnyObject?-in-an-Any when we unexpectedly receive a nil.
- If a parameter type is a sugared function type, mark the type
as non-escaping by default. Previously, we were only doing this
if the parameter type was written as a function type, with no
additional sugar.
This means in the following cases, the function parameter type
is now non-escaping:
func foo(f: ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: Fn)
- Also, allow @escaping to be used in the above cases:
func foo(f: @escaping ((Int) -> Void))
typealias Fn = (Int) -> Void
func foo(f: @escaping Fn)
- Diagnose usages of @escaping in inappropriate locations, instead
of just ignoring them.
It is unfortunate that sometimes we end up desugaring the typealias,
but currently there are other cases where this occurs too, such as
qualified lookpu of protocol typealiases with a concrete base
type, and generic type aliases. A more general representation for
sugared types (such as an AttributedType sugared type) would allow
us to solve this in a more satisfactory manner in the future.
However at the very least this patch factors out the common code
paths and adds comments, so it shouldn't be too bad going forward.
Note that this is a source-breaking change, both because @escaping
might need to be added to parameters with a sugared function type,
and @escaping might be removed if it appears somewhere where we
do not mark function types as non-escaping by default.
Since the ExpressibleByStringInterpolation protocol is also deprecated
now, it makes little sense to suggest using it instead of
StringInterpolationConvertible. Instead, the message now recommends
considering an init(_:String).
See
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160808/026171.html
for some more details.
