[swift-evolution] [Meta] Let's talk TouchBar + Unicode

[Xiaodi Wu]

There are two proposals in here that you're mixing together.

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.

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.

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.

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.

On Fri, Oct 28, 2016 at 20:54 Jonathan Hull <jhull at gbis.com> wrote:

>
> > On Oct 28, 2016, at 5:45 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> >
> > -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.
> 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.
>
> 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).
>
>
> > The same argument about the touch bar can be said for iPad soft
> keyboards.
> 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.
>
> Thanks,
> Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161029/75115ec9/attachment.html>