I see no need to remove the existing ternary command — for simple conditions of assignment (one condition, one then value, one else value) that fit on one line…. nested conditions regardless of syntax can quickly become nightmare.
What I would like to be able to do is write code in a functional paradigm by default, falling back to OOP / imperative where it makes sense because of the model or because of performance requirements. Preferably merging my other favorite language into Swift where it makes sense. Flow control becomes more of a byproduct of breaking things down into smaller and smaller tasks (recursion), and “statements" such as switch / match / if become just functions/expressions unto themselves. This means that the switch / match / if actually returns a value which if you are programming in a less functional way can just be ignored (maybe also by the compiler) and the “expressions” fall back to simple flow control statements. C style syntax is not bad just because it is C style - the vast majority of languages are derived from C style syntax - being different just to be different should not be the goal. > On 2015-12-22, at 20:59:06, Félix Cloutier via swift-evolution > <swift-evolution@swift.org> wrote: > > In my opinion, the operator has a future. Swift is merely moving away from > C-style constructs that promote mutable state. This kind of inline switch > expression actually reminds me of pattern matching constructs in functional > languages, and it may pick up more steam if the proposal for > single-expression functions from the functional folks goes in. > > I personally like the hybrid approach. > > Félix > >> Le 22 déc. 2015 à 04:07:34, Tino Heth via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >> Hi there, >> >> I don't think the operator has a future in Swift: >> Considering that the C-style for-loop and ++/— are doomed, "?:" would look >> like a living fossil in the language. >> "??" can handle one use case really well, and if/switch aren't that bad in >> the other cases. >> I'm quite sure those arguments already came up in the thread, so here is my >> conclusion: >> I don't vote for ?: to be removed, but I wouldn't like to see a replacement >> that has more complexity. >> >> Best regards, >> Tino >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
