> On 26 Oct 2016, at 18:57, Jon Akhtar via swift-evolution
> <[email protected]> wrote:
>
> 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#.
While I agree on most of this, I think there is reasonable justification to
discuss this on the basis of it using the question-mark; Swift uses the
question mark extensively for handling of optionals, so there is an element of
confusion present there, it also uses the colon in a somewhat unfamiliar way as
well, so it's a twofold oddity in Swift.
That said, I'm not sure replacing it with a function is superior; this is
something you can do yourself easily enough if you feel you need to, and which
learners can likewise do if they don't know about, or don't like the operator.
So the question really is whether there's an alternative that is similarly
concise, and on that I'm not so sure, so I'd lean towards leaving it as it is,
but advising people to be careful about where they use it, as its very
advantage in size can be a disadvantage in readability, so it should be used
with care at all times.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
