There are two proposals in here that you're mixing together.<br><br>One has to do with improvements to Xcode for working with Unicode. I'd be all for that, as I've just said, but afaict this is not in scope for Swift evolution.<br><br>The other has to do with expanding Swift standard library and core library APIs beyond the ASCII character set. I'm -1 on that for the reasons I've outlined above. Reworded, a very good reason to limit the standard library itself to ASCII APIs is the same reason we limit the library to (a restricted subset of) U.S. English. We do not all share a common first language or recognize the same characters, but these are reasonable common denominators with historical precedent in computer science *and* reasonably wide international recognition.<br><br>Given the adage here that code is more frequently read than written, it is unreasonable to require someone to master both "form union" and the union operator when one of these will do. While you and I are comfortable with set algebra notation, not everyone who uses Swift will be, and currently they *do not have to be* in order to be perfectly proficient at Swift. It does not sway me that you can now more easily type a character on a potential future device. It matters to me that someone not familiar with set algebra would have a hard time even looking up what such a non-ASCII character is when he or she first encounters it in, say, a textbook.<br><br>Now, to be clear, a third-party Swift library should be free to adopt any language or character set, and we should make the tooling as robust and convenient as possible for that use case, but the choice for Swift standard library APIs--themselves deliberately restricted in scope--should be the minimum required for clearly expressing what these APIs are. A person should not need to buy a special keyboard or device, or know how to work the option/alt key, in order to write the less-than-or-equal-to operator. OTOH, there's nothing wrong with a third-party project to decide that its API will be Sanskrit-only and require proficiency in the associated script for use.<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 28, 2016 at 20:54 Jonathan Hull <<a href="mailto:jhull@gbis.com">jhull@gbis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Oct 28, 2016, at 5:45 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> -1. I'm all for full and complete Unicode support in Swift so that each person can use their native language to the fullest. But there is value in saying that the working language for Swift evolution is U.S. English, the working language for the Swift standard library API is U.S. English, and the working character set for the core language facilities is ASCII. We've discussed and rejected union operators in the stdlib; it was a heated discussion, but we simply can't revisit API naming every six months.<br class="gmail_msg">
It was mainly rejected based on being too hard to type. It turns out that that decision was short-sighted. I am saying we need to stop being short-sighted. I honestly don’t see the value in limiting ourselves to ASCII anymore. Let’s be expressive in the best way we can. If a symbol is more expressive in one case, let’s use it. If a word is more expressive in another, let’s use that. But applying (now artificial/unnecessary) constraints because it is what our forefathers did is not helpful.<br class="gmail_msg">
<br class="gmail_msg">
I am reminded of the time, when I was writing my thesis (on Undo) in User Experience, they were trying to force us to put our charts, tables, and figures in a very unreadable format. Why? Because it made it easier for printing presses in the 1850’s, and the rules had been codified based on that. It didn’t matter that we were now printing on laser printers. Everyone was forced to do something suboptimal because it was what those in charge had been forced to do in their day as well. Arbitrarily forcing part of the system to be restricted to ASCII despite the fact that it now supports unicode is similarly silly (and similarly harmful).<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> The same argument about the touch bar can be said for iPad soft keyboards.<br class="gmail_msg">
Yes, yes it can. Programming on the iPad will be a real thing before you know it. We need to avoid limiting ourselves to the constraints of the 1970s.<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
Jon</blockquote></div>