> On Aug 31, 2017, at 3:16 PM, Taylor Swift via swift-evolution > <[email protected]> wrote: > Where is the source for this number? XCode is not even available for Linux. > And XCode’s market share is only shrinking as Swift expands more into the > open source world. To make Swift depend on proprietary XCode features would > nullify all of the work that has been done in the past 2 years to bring Swift > to Linux platforms. > > On Thu, Aug 31, 2017 at 12:44 PM, John Pratt <[email protected] > <mailto:[email protected]>> wrote: > XCode is not just one of many editors to edit Swift you asshole.
John, this sort of personal attack is not acceptable behavior in the Swift community, and sending it privately does not alter that. If you would like to continue participating in this community, please learn to treat your fellow contributors with respect. I don't think this thread is entirely off-topic. While Swift as a language is committed to allowing code to be edited in a simple text editor, we also recognize the importance of graphical programming environments, and we are certainly open to adding features that primarily benefit them — as we did with color and resource literals. Of course, it would necessary to show that the language feature was both necessary and likely to see significant editor adoption. At least some of these ideas, like rendering a power operator with a superscript, do seem like they could implemented in an editor without any language support. John. > > > >> On Aug 31, 2017, at 11:27 AM, Taylor Swift <[email protected] >> <mailto:[email protected]>> wrote: >> >> If you ask me this thread is off topic and belongs on an Apple issue tracker >> or forum. XCode is just one of many editors used to edit Swift code, and it >> should by no means be used as a baseline for language design considering it >> is closed source and only available on one platform, compared to a large >> number of great open source editors. >> >> On Thu, Aug 31, 2017 at 7:53 AM, Jonathan Hull via swift-evolution >> <[email protected] <mailto:[email protected]>> 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) >> >> 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. >> >> 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. >> >> 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 ‘≤’). >> >> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
