This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
These types are leftovers from the early pre-1.0 times when Int and UInt
were always 64-bit on all platforms. They serve no useful purpose
today. Int and UInt are defined to be word-sized and should be used
instead.
rdar://18693488
Swift SVN r30564
Per Dmitri's request and stdlib conventions. Also, remove the reference to
what's now '_value' from the DarwinBoolean tests, and use unsafeBitCast
instead to mimic representation-compatible access from C.
Swift SVN r30066
Depends on a clang change to target info, and an objc4 change to the
Objective-C headers, which accomplish the actual ABI change for Swift.Bool.
This commit updates ObjCBool and adds a test.
rdar://problem/21294221
Patch by Ben Langmuir.
Swift SVN r29423
For integral types, the WatchKit remote procedure call mechanisms only
consider signed numbers (rdar://problem/21153645) and the boolean
type. We were incorrectly assuming that all bools are i1, even on
platforms where bool maps to signed char, such as armv7k, arm64, and
iOS x86_64.
Mark Objective-C type encoded strings that bool -> signed char
when Clang says so.
Fixes: rdar://problem/21129609
See Also: rdar://problem/21131808
Swift SVN r29141
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
includes a number of QoI things to help people write the correct code. I will commit
the testcase for it as the next patch.
The bulk of this patch is moving the stdlib, testsuite and validation testsuite to
the new syntax. I moved a few uses of "as" patterns back to as? expressions in the
stdlib as well.
Swift SVN r27959
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
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
