[swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[Alex Blewitt]

> On 31 Aug 2017, at 13:53, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> 
> A few thoughts:
> 
> 1) I would like to see Xcode gain a couple more literal types using the same strategy it does for Image and Color literals
> 
> 2) I would LOVE to see simple equation typesetting in Xcode
> 
> (Those two are mostly up to the Xcode team as opposed to swift, I suppose)

Please file radars at https://bugreport.apple.com <https://bugreport.apple.com/> for enhancement requests for Xcode.

> 3) Why are we pretending like we can always edit swift in a ASCII editor?  The argument that actually using unicode would break things doesn’t seem valid, because Swift has supported unicode since version 1, and people have been using it since that time to name both variables and operators. That doesn’t mean we need a super fancy editor, but I think requiring unicode awareness is completely reasonable.  If your editor from the 1970’s breaks something, it is both your and your editor’s fault, not the code or the library, because Swift has unicode in it’s spec.

The unicode support in Swift is not entirely dissimilar to unicode support in other languages. Java had Unicode support from the beginning as well (although pre-Emoji) and you can use identifiers as function names. Note however that ≤ is treated as a non-Java identifier part, so you can't use that in this particular case:

http://www.fileformat.info/info/unicode/char/2264/index.htm

The issue isn't to do with whether it breaks an editor or not, but in practice you don't get people using operators because they're difficult to type, rather than whether the editor can render them or not.

> 4) I don’t think we should let the difficulty of typing certain things stop us.  It is an issue we need to consider, but it is an issue which can be solved fairly easily with good UI design if there is a need. Sure, different editors might solve it in different ways, but they will all solve it if it is useful (and in a few years, we will have all settled on the best approach).  As people have mentioned, it can be difficult to type ‘{‘ on certain language layouts, so if we limited ourselves by that we couldn’t do anything.  We shouldn’t adopt a lowest common denominator approach.

No-one is preventing you from creating a library that uses these operators, though. The success and adoption of that library can be used to influence whether that will be beneficial to be in other libraries.

> 5) The lack of ‘≤’ has driven me absolutely nuts since Swift 1. It won’t be confusing if we let people do either ‘<=‘ or ‘≤’ (there is research by Apple in the late 80’s that proves this).  We all learned the symbol in math class. Even non-programmers know what it means.  Assigning it any other meaning would be confusing because it’s meaning is so widely known.  Every time I bring this up, I am told to just roll my own (which I have)… but it means that my code will now clash with everyone else’s identical implementation (because there is only one sane way to implement it).  The fact that there are multiple identical implementations interfering with each other (and no real way to make a significantly different implementation) tells me it really should be part of swift itself. Every time I bring it up, people complain about it being extended ASCII instead of pure ASCII, and that it is hard to type on a German keyboard (those people can either just type ‘<=‘ or use a better editor which autocompletes ‘<=‘ to ‘≤’).

Nothing is preventing you creating a library which defines the ≤ operator and then including that in your projects for when you want to use it. You can even provide this for others who have expressed an interest on this list.

> 6) My recommendations for typing symbols would be:
> 	a) Choose a subset of useful and well-known symbols instead of every symbol
> 	b) Allow autocomplete on those symbols by name
> 	c) Optionally choose a little-used guardian character to start the names of symbols (to avoid accidental autocompletion). 
> 
> Thanks,
> Jon
> 
> 
>> On Aug 28, 2017, at 7:57 PM, John Pratt via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I sent a postal envelope to the Swift team with an article I wrote, arguing that
>> symbols and graphics would push the programming language forward.
>> 
>> Wouldn’t it be nice to have an actual multiplication matrix broken out into code,
>> instead of typing, “matrix()”?  It seems to me Swift has the chance to do that.
>> 
>> Also: why does "<==" still reside in code as "less than or equal to” when
>> there is a unicode equivalent that looks neat?  
>> 
>> Why can’t the square of x have a superscript of 2 instead of having “pow(x,2)?  
>> I think this would make programming much easier to deal with.
>> 
>> I expound on this issue in my article:
>> 
>> http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf <http://www.noctivagous.com/nct_graphics_symbols_prglngs_draft2-3-12.pdf>
>> 
>> Thank you for reading.
>> 
>> 
>> -John
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170831/147985fa/attachment.html>