+1 to Jon's answer. -1 to the proposal. I have argued in the past for introducing an if-then-else expression instead of the ternary operator but I wouldn't replace it with a clunky function which reduces readability a lot IMHO.
-Thorsten > Am 26.10.2016 um 19:57 schrieb Jon Akhtar via swift-evolution > <[email protected]>: > > I think that we need to get past the “leftovers from C” being a bad thing > mindset. Familiar constructs make Swift easier for programmers (its target > audience) easier to learn. > > Point by point: > > Being a holdover from C isn’t a bad thing. We can take things that were > useful in C and make them part of Swift. Who said C language elements were a > non-goal of Swift. And to the “ternary operator is hard to learn” point. This > point gets made over and over in proposals to change Swift, ease of learning > is like performance and security – you can never have enough so there is no > counter-argument. If you can’t learn the ternary operator, Swift isn’t the > language for you, because what are you going to do when you get to generics > and higher order functions. > If the ternary operator adds complexity to the compiler then it really isn’t > a holdover from C. We have quite a long time to know how to parse it from our > C legacy. > See #1, new users are always confused about everything. They don’t stay that > way. The language doesn’t need to be tuned to support it’s non-users. Most > developers understand the ternary operator, and it is useful to them. Who is > this language for? > The “:” appears in other places in the grammar. So what. So do parenthesis > and brackets. It is just a token used in a grammar rule as a separator, it > doesn’t have a meaning on its own, and it shouldn’t have one that isn’t its > function. > So your argument is to make the ternary expression longer to discourage > nesting. This is much different than the argument for function(a++, ++a) > where order of function parameter evaluation influenced the code, but was not > expressed by it. Everything is fully expressed by the ternary operator > including order of evaluation. > I see no problem with it being limited to bool. I don’t want Javascript’s “” > == false. > What would be proposed (and has been) is the if expression which is more > verbose but easier to read > Again, the C hate. > You leave out the reason for those languages to leave out the ternary > operator. What was their rationale? > I’m sorry you had a hard time with it. But you learned it, and now you can > apply that knowledge to any language that has it. To add to the anecdotal > evidence you provided, I did not have a hard time learning it. > I can distill this down to “C is old and not modern so lets get rid of > anything from C” and “I had a hard time learning the ternary operator" > > Bottom line, most developers know the ternary expression if they come from C, > C++, Obj-C, Java, C# (The list goes on). Why does Swift need to be different > for style reasons. We will be making a niche language, because what you learn > isn’t portable to another language like it is if you learn Java, then get a > job programming in C#. > > > > From: <[email protected]> on behalf of Mark Sands via > swift-evolution <[email protected]> > Reply-To: Mark Sands <[email protected]> > Date: Wednesday, October 26, 2016 at 09:55 > To: William Sumner <[email protected]> > Cc: Swift-Evolution <[email protected]> > Subject: [External] Re: [swift-evolution] [Pitch] Replace the ternary > operator with an in-language function > > > >> Training users to expect source-breaking churn would be highly damaging to >> the language. The removal of C-style for loops and increment/decrement >> operators came with sufficient justification beyond their being inherited >> from C. I don’t think there’s a sufficient justification for this change, >> especially with the bar set high for such changes. >> >> Preston > > My apologies for skewing the conversation off-topic. I think what I meant to > imply is that we shouldn't be afraid of a deprecation warning. Migrating away > from a ternary operator is trivial, and the consequences usually come with > better readability. > > Ignoring my statement about "leftovers from C" opposition, I do think there > is sufficient and very strong justification from the 10 items that Charlotte > has listed. I think it would be more valuable if one could pick apart each > bullet point they find excusable and list their reasons why it's not > compelling enough to warrant change. > + V2 Checkin API > + V2 Checkout API > + V2 Get Admission Records [Updated] > + V2 Get Scan Records > - New SQLite Data File generation > - V2 Get User Events > - V2 Scan Record Submission > > - GDO Ticket Purchase Integration API > > - V2 Get Ticket Record(s) [New] > - V2 Ticket Creation API [Updated] > - V2 Ticket Info API [New] > - V2 Ticket Transfer API [New] > - V2 Ticket Re-issue API [New] > _______________________________________________ > 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
