This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
a let/var pattern. Now any identifier in one of these is a variable binding,
not sometimes a value references (depending on contextual syntax).
This isn't expected to have a widespread effect on existing real world code:
- No impact on the stdlib.
- It does fix two validation crash tests, but possibly because the original issue is hidden by a different diagnostic path in the compiler.
- This needed two tests to be tweaked to undistribute "let".
On the positive side, this means that "case let x?:" now works properly, woo.
Swift SVN r26000
These APIs will be used for writing automation tools in Swift. Just
like other private APIs, this module is not exposed to extrenal users.
The primary motivation for doing instead of using NSCoder this is that
NSCoder does not work with structs and Swift containers. Using classes
for everything just to satisfy NSCoder forces unnatural code.
This API requires two times (!) less boilerplate than NSCoding, since
the same method is used for serialization and deserialization. This API
is also more type-safe, it does not require the user to write 'as' type
casts, unlike NSCoding.
Please take a look at
validation-test/stdlib/SwiftPrivateSerialization.swift to see the
intended use pattern.
The performance of the underlying implementation is already decent, and
there's a lot of room for improvement.
This is a re-commit of r25678, with a fix for 32-bit platforms.
Swift SVN r25877
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
This reverts commit r25678, which breaks the build:
/Users/dgregor/Projects/Apple/swift/stdlib/serialization/MsgPack.swift:117:34: error: integer literal overflows when stored into 'Int'
} else if utf8Bytes.count <= 0xffff_ffff {
^
/Users/dgregor/Projects/Apple/swift/stdlib/serialization/MsgPack.swift:139:34: error: integer literal overflows when stored into 'Int'
} else if dataBytes.count <= 0xffff_ffff {
^
/Users/dgregor/Projects/Apple/swift/stdlib/serialization/MsgPack.swift:160:24: error: integer literal overflows when stored into 'Int'
} else if count <= 0xffff_ffff {
^
/Users/dgregor/Projects/Apple/swift/stdlib/serialization/MsgPack.swift:189:31: error: integer literal overflows when stored into 'Int'
} else if mappingCount <= 0xffff_ffff {
^
/Users/dgregor/Projects/Apple/swift/stdlib/serialization/MsgPack.swift:235:29: error: integer literal overflows when stored into 'Int'
} else if data.count <= 0xffff_ffff {
^
Swift SVN r25693
The new modules are:
* SwiftUnstable -- assorted additions to the core standard library
(more algorithms etc.)
* SwiftUnstableDarwinExtras -- proposed additions to the Darwin overlay,
not yet reviewed by the Darwin team.
* SwiftUnstablePthreadExtras -- wrappers that make it possible to
use pthread in Swift (they work around the lack of block-based API in
pthread). In future these could be possibly folded into the Darwin
overlay as well.
These APIs are useful without StdlibUnittest for writing automation
tools in Swift. Just like SwiftExperimental, none of these modules are
exposed to extrenal users.
Also, since these new modules can be compiled with -sil-serialize-all
(unlike StdlibUnittest, where we can't apply the flag because of
compiler bugs), standard library tests that need to run optimized code
(like AtomicInt.swift) are *much* faster now.
Swift SVN r25679
The primary motivation for doing this is that NSCoding does not work
with struts and Swift containers. Making everything classes just to
satisfy NSCoding forces unnatural code.
This API requires two times (!) less boilerplate than NSCoding, since
the same method is used for serialization and deserialization. This API
is also more type-safe, it does not require the user to write 'as' type
casts, unlike NSCoding.
Please take a look at validation-test/stdlib/Serialization.swift to see
the intended use pattern.
The performance of the underlying implementation is already decent, and
there's a lot of room for improvement.
These APIs will be used for writing automation tools in Swift. Just
like SwiftExperimental, this module is not exposed to extrenal users.
Swift SVN r25678
<rdar://problem/19919467> Interpreter/repl.swift regressed under ASan
<rdar://problem/19919459>
compiler_crashers/0214-swift-typebase-gettypeofmember.swift regressed
under ASan
Swift SVN r25483
<rdar://problem/19803733> String#append(Character) is broken in Swift 1.2 (beta)
<rdar://problem/19809905> Swift 1.2: join does not work with Emoji strings
Swift SVN r25449
When referring to a type declaration that is a member of some nominal
type, we were relying on substitution into the non-interface type,
which is silly. Use the interface type here.
Other than some type-printing differences, this should be NFC.
Slight regression in two compiler crashes that had been fixed in the
previous commit; I'll look into these shortly.
Swift SVN r25385
Previously, we were reconstructing this mapping from the "full" opened
type produced by declaration references. However, when dealing with
same-type constraints between associated types and type parameters, we
could end up with an incomplete mapping, which let archetypes slip
through. Most of the churn here is sorting out the locators we need to
use to find the opened-type information. Fixes rdar://problem/18208283
and at least 3 dupes of it that I've found so far.
Swift SVN r25375
