Same with 2016-01-11

Comments copied from SR-640, as I had missed this one:
On OSX:

$ swift
Welcome to Apple Swift version 3.0-dev (LLVM f95d47afa7, Clang f66c5bb67b, Swift b745691a38). Type :help for assistance.
  1> "t" < "Tt"
$R0: Bool = false

On Linux:

$ swift
Welcome to Swift version 2.2-dev (LLVM f90171f6b9, Clang fe39b0b18f, Swift a476c2828a). Type :help for assistance.
  1> "t" < "Tt"
$R0: Bool = true

Unfortunately, it's not clear how/whether to fix the problem, because of the number of times this is mentioned as a possibility in the source code. What is the desired behaviour? The String documentation implies the "Standard Sort Order" is expected, but NSString does not do that. The NSString behaviour is probably closer to "American English (Computer, Standard Sort Order)".

I believe that a bug lies within the string comparison, as a comment within the comparison logic for String mentions:

    // Note: this operation should be consistent with equality comparison of
    // Character.

However, from a Linux system, the comparison is not equivalent to Character:

  1> let x: Character = "A"
x: Character = {
  _representation = small {
    small = 9223372036854775617
  }
}
  2> let y: Character = "a"
y: Character = {
  _representation = small {
    small = 9223372036854775649
  }
}
  3> x < y
$R0: Bool = true
  4> "A" < "a"
$R1: Bool = false

The issue seems to lie with the processing done with UCollator within UnicodeNormalization.cpp. It appears to not be configured for case sensitivity.

Comment by Pavel Ivashkov (JIRA)

This applies not only to case sensitivity, as seen on SO

"2" < "=" // true on macOS, false on Linux

opened #8769

This will mostly be fixed by the new string work, wherein String's default sort order will be implemented as a lexicographical ordering of FCC-normalized UTF16 code units.

Note that on both platforms we rely on ICU for normalization services, and normalization differences among different implementations of ICU are a real possibility, so there will never be a guarantee that two arbitrary strings sort the same on both platforms.

However, for Latin-1 strings such as those in the example, the new work will fix the problem.

Comment by Lance Parker (JIRA)

This will be resolved by: https://github.com/apple/swift/pull/13877

Comment by Lance Parker (JIRA)

This has been fixed in 4.2