is performed according to the deterministic Unicode collation algorithm,
which allows us to use the hash of the NFD form.
rdar://17498444
Swift SVN r20543
normalization
There is still some obscure bug with != on NSString, probably caused by
an ill-thought overload somewhere.
Part of rdar://17498444
Swift SVN r20518
normalization
There is still some obscure bug with != on NSString, probably caused by
an ill-thought overload somewhere.
Part of rdar://17498444
Swift SVN r20495
The length could already be given by the input sequence. Also, make it
accept any generic Sequence of bytes, rather than requiring an array.
Fixes <rdar://problem/17034413>
Swift SVN r20480
...because their semantics were unclear. The new idiom is explicit
construction of the target type using the "bitPattern:" argument label:
myInt.toUnsigned() => UInt(bitPattern: myInt)
Fixes <rdar://problem/17000821>
Swift SVN r20479
+= only extends arrays with another sequence of the same element type.
Fixes <rdar://problem/17151420> The use of the overloaded += operator in
Swift is inconsistent and confusing with Arrays.
Note that this commits generated 3 new radars against the type checker:
<rdar://problem/17751308>
<rdar://problem/17750582>
<rdar://problem/17751359>
Swift SVN r20274
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
Foundation, and have them forward to Foundation.
This is slower than it could be, but at least this way we produce correct
results.
Another part of rdar://17550187
Swift SVN r19560
There is some follow-up work remaining:
- test/stdlib/UnicodeTrie test kills the type checker without manual type annotations. <rdar://problem/17539704>
- test/Sema/availability test raises a type error on 'a: String == nil', which we want, but probably not as a side effect of string-to-pointer conversions. I'll fix this next.
Swift SVN r19477
This consolidates the \x, \u, and \U escape sequences into one \u{abc} escape sequence.
For now we still parse and cleanly reject the old forms with a nice error message, this
will eventually be removed in a later beta (tracked by rdar://17527814)
Swift SVN r19435
algorithm
The implementation uses a specialized trie that has not been tuned to the table
data. I tried guessing parameter values that should work well, but did not do
any performance measurements.
There is no efficient way to initialize arrays with static data in Swift. The
required tables are being generated as C++ code in the runtime library.
rdar://16013860
Swift SVN r19340
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
In UTF-8 decoder:
- implement U+FFFD insertion according to the recommendation given in the
Unicode spec. This required changing the decoder to become stateful, which
significantly increased complexity due to the need to maintain an internal
buffer.
- reject invalid code unit sequences properly instead of crashing rdar://16767868
- reject overlong sequences rdar://16767911
In stdlib:
- change APIs that assume that UTF decoding can never fail to account for
possibility of errors
- fix a bug in UnicodeScalarView that could cause a crash during backward
iteration if U+8000 is present in the string
- allow noncharacters in UnicodeScalar. They are explicitly allowed in the
definition of "Unicode scalar" in the specification. Disallowing noncharacters
in UnicodeScalar prevents actually using these scalar values as internal
special values during string processing, which is exactly the reason why they
are reserved in the first place.
- fix a crash in String.fromCString() that could happen if it was passed a null
pointer
In Lexer:
- allow noncharacters in string literals. These Unicode scalar values are not
allowed to be exchanged externally, but it is totally reasonable to have them
in literals as long as they don't escape the program. For example, using
U+FFFF as a delimiter and then calling str.split("\uffff") is completely
reasonable.
This is a lot of changes in a single commit; the primary reason why they are
lumped together is the need to change stdlib APIs to account for the
possibility of UTF decoding failure, and this has long-reaching effects
throughout stdlib where these APIs are used.
Swift SVN r19045
rangeOfCharacterFromSet(_:options:range:)
The underlying Objective-C API could return an NSRange of NSNotFound. Swift's
String.Index can not represent that, so change the API to return an optional
Swift Range<Index> instead.
Swift SVN r18679
stringWithBytes(_:length:encoding:) was passing an array to Objective-C
incorrectly, and a garbage NSString was being constructed as a result.
Unhide the initializer was accidentally hidden.
Swift SVN r18674
Many changes in how we're presenting the NSString APIs on String, most
notably that we now traffic in String.Index and Range<String.Index>
rather than Int and NSRange. Also we present NSString initializers that
can fail only as factory functions, and factory functions that can't
fail only as init functions.
About 25% of the API changes here have been reviewd by the Foundation
guys, and testing is, as it has always been, admittedly spotty. Dmitri
is going to be writing some more comprehensive tests.
Swift SVN r18553
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
Because we're using a "brute-force" combination of conversion to
NSString and forwarding, this code will continue to work when String
is replaced by NewString. It may not be fast yet, but at least it
will flesh out the experience for Cocoa programmers
Swift SVN r11034
