-1 I agree with Jeremy and Xiaodi with regards to adding non-ASCII characters to the language core/standard library. Jeremy summed it up nicely here, emphasis mine:
"This I agree with 100%: the functions and operators of the standard library have to be typed in by everybody who programs in Swift. *Not everybody has a MacBookPro with a touch bar* (in fact, not anybody just yet, except for a lucky few). *Not everybody wants to program with an iPad*. Some people *even like to program in Swift with text editors that aren’t Xcode. I expect there are programmers (especially on Linux) whose preferred editor is vi or even Emacs.* For that reason, the Swift Standard Library has to be fairly lowest common denominator in terms of characters used." I frequently code Swift on Linux with both vi and Emacs, and I'm on touch-typist keyboards (Das Keyboard w/ no glyphs) with years of muscle memory typing quick sequences such as <= or !=. Adding glyphs that cannot be typed with 1 or 2 sequences (i.e., relying on a touchbar or relying on an editor recognizing the "macOS-style" sequence of holding a key down long enough to get options) or adding :less-than-or-equal-to: would be an unwelcome addition. -Joe On Mon, Oct 31, 2016 at 9:07 AM, Jeremy Pereira via swift-evolution < [email protected]> wrote: > > > On 29 Oct 2016, at 03:22, Xiaodi Wu via swift-evolution < > [email protected]> wrote: > > > > > > 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. > > Somebody not familiar with set algebra is not going to understand what > “formUnion” means either. Either way they are going to have to look it up. > Google returns the link in the Apple documentation as the top hit for > formUnion, and it returns the Wikipedia page for set unions for ∪, so not a > terrible disaster for discoverability. However … > > > > > 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. > > This I agree with 100%: the functions and operators of the standard > library have to be typed in by everybody who programs in Swift. Not > everybody has a MacBookPro with a touch bar (in fact, not anybody just yet, > except for a lucky few). Not everybody wants to program with an iPad. Some > people even like to program in Swift with text editors that aren’t Xcode. I > expect there are programmers (especially on Linux) whose preferred editor > is vi or even Emacs. For that reason, the Swift Standard Library has to be > fairly lowest common denominator in terms of characters used. > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > -- Joseph Bell http://dev.iachieved.it/iachievedit/ @iachievedit
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
