> On 31 Aug 2017, at 15:47, Jonathan Hull <[email protected]> wrote:
>
>> On Aug 31, 2017, at 6:53 AM, Alex Blewitt <[email protected]
>> <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
