> On Aug 31, 2017, at 6:53 AM, Alex Blewitt <alb...@apple.com> wrote:
> Please file radars at https://bugreport.apple.com
> <https://bugreport.apple.com/> for enhancement requests for Xcode.
Thanks. Will do.
>> 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.
I have and will continue to. I would like to see support for making this
easier in Xcode (which is another radar). My main argument here is that we
should not shy away from at least considering options which require these
operators in the standard library (if they are the best design). Right now all
talk of it gets shut down immediately by a few very aggressive/vocal folks.
Maybe it is the right design or maybe it isn’t… but we should at least be able
to consider all of our options.
>> 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. 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. 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.
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. It seems extra ridiculous because those definitions are all
basically identical. Do you see the issue?
Thanks,
Jon_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
