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.
This removes conformance of DarwinBool and ObjCBool to the Boolean protocol,
and makes the &&/||/! operators be concrete w.r.t. Bool instead of abstract
on Boolean.
This fixes some outstanding bugs w.r.t diagnostics, but exposes some cases
where an existing diagnostic is not great. I'll fix that in a later patch
(tracked by rdar://27391581).
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
This documentation revision covers a large number of types & protocols:
String, its views and their indices, the Unicode codec types and protocol,
as well as Character, UnicodeScalar, and StaticString, among others.
This also includes a few small changes across the standard library for
consistency.
This revises and expands on documentation for the new collection methods
for working with indices and the revised Swift 3 set APIs. In addition,
it includes documentation for the new range types.
semantically unambiguous.
We didn't actually intend to change how programmers normally
constructed these types, but the change to the object literal
syntax accidentally caused these initializers to have very
natural-seeming signatures. These initializers also created
possible ambiguities with the actual initializers. Renaming
them to refer to their function as literal initializers is the
right thing to do.
Unfortunately, this provided to be somewhat annoying, as the
code was written to assume that the argument tuple following
e.g. #colorLiteral could be directly passed to the initializer.
We solve this by hacking on both ends of the constraint system:
during generation we form a conversion constraint to the
original, idealized parameter type, and during application we
rewrite the argument tuple type to use the actual labels.
This nicely limits the additional complexity to just the
parts dealing with object literals.
Note that we can't just implicitly rewrite the tuple expression
because that would break invariants tying the labels to physical
source ranges. We also don't want to just change the literal
syntax again and break compatibility with existing uses.
rdar://26148507
* Implement the majority of parsing support for SE-0039.
* Parse old object literals names using new syntax and provide FixIt.
For example, parse "#Image(imageLiteral:...)" and provide a FixIt to
change it to "#imageLiteral(resourceName:...)". Now we see something like:
test.swift:4:9: error: '#Image' has been renamed to '#imageLiteral
var y = #Image(imageLiteral: "image.jpg")
^~~~~~ ~~~~~~~~~~~~
#imageLiteral resourceName
Handling the old syntax, and providing a FixIt for that, will be handled in a separate
commit.
Needs tests. Will be provided in later commit once full parsing support is done.
* Add back pieces of syntax map for object literals.
* Add parsing support for old object literal syntax.
... and provide fixits to new syntax.
Full tests to come in later commit.
* Improve parsing of invalid object literals with old syntax.
* Do not include bracket in code completion results.
* Remove defunct code in SyntaxModel.
* Add tests for migration fixits.
* Add literals to code completion overload tests.
@akyrtzi told me this should be fine.
* Clean up response tests not to include full paths.
* Further adjust offsets.
* Mark initializer for _ColorLiteralConvertible in UIKit as @nonobjc.
* Put attribute in the correct place.
We can mark a container as _DestructorSafeContainer only if whether it may
store to memory on destruction only depends on its type parameters destructors.
In swift 1.2, `Slice` has been renamed `ArraySlice`.
In swift 2.0, type parameter name of `Array` is changed from `T` to `Element`.
Therefore, modified the names which appear in code comments and a document.
literal initializer to underlying failable initializer through
implicitly-failable initializer (proper solution is covered in
22276505).
<rdar://problem/20788137> Image literals should not be optional
Swift SVN r31229
Like ObjCBool is a legitimate boolean type rather than a typealias for Int8,
DarwinBoolean is better than a typealias for UInt8. It's a BooleanType
(meaning you can use it directly in if/while/?:) and BooleanLiteralConvertible
(meaning you can use 'true' and 'false').
The next commit goes even further, so that you only have to deal with
DarwinBoolean when ABI is important. At all other times it should be
bridged with Bool, just like ObjCBool.
rdar://problem/19013551
Swift SVN r30050
Now that we are using OptionSetType for option sets, all the support for
doing things the old way can die.
Note: the fix-it that used to apply to RawOptionSetType, it seemed to me,
should still apply to OptionSetType, so I switched it over instead of
removing it.
Swift SVN r29066
