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

[Alex Blewitt]

> On 31 Aug 2017, at 15:47, Jonathan Hull <jhull at gbis.com> wrote:
> 
>> On Aug 31, 2017, at 6:53 AM, Alex Blewitt <alblue at apple.com <mailto:alblue at apple.com>> wrote:
> 
> 
>>> 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.
> 
> But there is something that is preventing me and others from doing this in open source code.

No, nothing prevents you from doing it in open source code. If you have done this already, please share the link so that others may benefit from your work.

swift-evolution is designed to discuss and advance the language of the Swift language, and the core data components that make the language necessary. There's a lot of extra functions and data types in the swift-corelibs-foundation project that don't belong in the core of Swift either.

> I have written my own library with this (it was one of the first things I wrote in swift) and there are several others available online.

OK, so link to them, and get the various parties to agree on using one definition instead of several.

> The issue is that if I want to include another framework, and that framework has also defined it (or more likely relies on another framework that defines it) then swift gets upset about the multiple definitions.  I really want to rely on those libraries, but if it makes my own framework have a danger of conflicts with other libraries then it will stop adoption of my framework as a result.

This hasn't stopped a number of others from relying on types they've defined, like the Result type, for example.

> That is the main reason I am arguing that it needs to be in a central spot… we are all prevented from really doing it on our own because multiple definitions conflict.

Have you submitted pull requests to those projects to try and unify them to a single spot? What was the outcome of those reviews?

> It seems extra ridiculous because those definitions are all basically identical.  Do you see the issue?

There's a difference of expectations here as to the purpose of the swift-evolution list. It's not about growing personal preferences of how to achieve that which is already available and possible to do today.

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