The complaint that you have about Javascript is more a function of it not being a strongly typed language. If you were to write a function with the type of return specified and the code inside the function (because of a single character) end up changing type for the return value or a future expression that was not expecting boolean…. then it would not compile.
> On 2015-12-20, at 13:35:42, Charles Constant via swift-evolution > <swift-evolution@swift.org> wrote: > > > keeping expressions and statements as separate concepts > > I seriously could not care less about that. > > Wait wait, I'm exaggerating! I wouldn't want Swift to become a language like > Javascript where you forget to type a single character, and discover your > program runs without complaint (assigning some bizarre boolean value as a > result). > > But if we're talking about the 'Switch' statement, as originally proposed, it > takes a lot more characters, and luck, to get your app to compile and run. > For me, I'd way rather have the convenience. As far as I'm concerned, unless > I'm choosing a variable name, the more I have to type, the more likely I'm > going to make a mistake. > > This is why I think the ternary, for example, gets a bad rap (a bad rap *at > the moment* anyway. I can't keep track, are "goto" and OOP bad this year?). > The clarity you gain with a ternary is the fact that "this statement exists > to assign a value to Foo." You break that into several lines, and that > clarity can evaporate into the ether. > > So the reason I like your proposal, is that I want a way to preserve that > clarity of "this line exists to assign a value to Foo" when I'm mapping > something. The existing options, i.e.: the alternatives about I complained > earlier in this thread, leave me with extra code whose purpose is solely to > support that assignment to Foo. So, let's say I do it by extending an enum > with an init that has a corresponding set of values... the purpose of that > extension is no longer as clear (e.g.: "this init exists to support a line, > somewhere else in this file, that assigns a value to Foo"). If I use a Switch > statement, as it currently exists, it's a bunch of lines - and don't forget > that "let Foo" needs to be declared *before* the Switch statement because of > scope... it's so much more complicated than your proposal. > > I don't know if I added anything helpful here other than complaining :) > Needless to say, I still support your proposal > > > > > On Sat, Dec 19, 2015 at 9:57 PM, Paul Ossenbruggen via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Dec 19, 2015, at 8:37 PM, Dennis Lysenko via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> +1 to Jordan's points as well. >> >> Generally speaking, there is clearly a wide variety of things that cause >> people to be interested in this particular proposal and I don't think we can >> reconcile all of them. For example, I think that "collapsing an if statement >> into one line" isn't a good enough reason to introduce the clutter and >> potential for abuse of the original ternary syntax into a codebase, so I >> generally float the idea to ban it from projects I'm involved in as soon as >> I see it pop up in one. At the same time, there seem to be people who are >> enamored with the concept, and maybe instead they talk in this thread >> because they want a way to condense a switch statement into one line. And >> still others think that there is no rush to think about getting rid of >> ternary, unless we come up with something equally concise or with >> significant advantages to warrant removing it (all valid points). >> >> I'm not against Paul's idea, but if it matters at all (i.e. if you are >> worried other people will think like me), if this syntax is released, I will >> most likely float the idea of opting out of it immediately to my project >> collaborators. >> >> While interesting for quick, proof of concept coding sessions, it already >> has some of the readability and abusability disadvantages already present in >> ternary, and it's still just in the proposal stage. >> >> I only hope that this doesn't preclude progress on turning fully-qualified >> (and indented) statements into expressions. > > Good feedback! > > Personally, I kind of hope that that is not the direction of Swift. I think > there is quite a bit of value in keeping expressions and statements as > separate concepts. If you need to do a bunch of things to get the result of > an expression then use the statement construct or move it into a method. > > Having statements that act as expressions encourages code that has side > effects, which goes against one of the core concepts of functional > programming. If I am working on a team, and someone wants to add some new > feature and they see a big indented “if” with braces, they will just stick it > in there and ignore that it is a functional approach. That new statement they > add may add a bunch of side effects and add bugs to the code. If it is an > expression that temptation will be less likely. They will see that this code > is intended to work as an expression and won’t be able to just stick another > statement with a bunch of side effects into it. > > My proposal is about making expressions into first class citizens in terms of > control flow. Its main purpose is definitely not about doing things on one > line, that is just a side benefit if it works for your particular situation. > This proposal supports and encourages multiline formatting and I think > actually makes things cleaner and clearer than the statement forms. > > But this feedback and Jordan’s is making me think that the Hybrid approach in > Alternatives Considered may be more appealing to everyone. I was thinking > conciseness might be preferable given some of the feedback I got from Chris > and others, but after reading some other threads, clarity wins out over > conciseness. This alternative may win for clarity. So I might go back and > rethink that, but before I do that, I hope that more people could tell me if > they like it better or do they like the ?( syntax better. > > - Paul > > >> >> On Sat, Dec 19, 2015 at 10:57 PM Dave Abrahams via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> > On Dec 19, 2015, at 7:55 PM, Jordan Rose via swift-evolution >> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> > >> > It's a nice, consistent proposal, but I don't feel like this solves any of >> > the complaints about the existing ternary operator: >> > >> > - It's not obvious what it does when you first learn it. >> > - The '?' doesn't have anything to do with Optionals. >> > >> > It is a way to put 'switch' into an expression. I'm not a fan of the two >> > different colons, but that's "just" syntax. >> >> +1 to all that >> >> > Jordan >> > >> >> On Dec 18, 2015, at 14:04 , Paul Ossenbruggen via swift-evolution >> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> >> All, >> >> >> >> I think, I finally might have the answer to improving ternary, with such >> >> a bold statement come some pretty high expectations but I think, I might >> >> actually have done it this time :-) >> >> >> >> I am calling it the Demux Expression, it builds on the benefits of >> >> ternary and switch while improving on those. >> >> >> >> https://github.com/possen/swift-evolution/blob/master/proposals/0024.md >> >> <https://github.com/possen/swift-evolution/blob/master/proposals/0024.md> >> >> >> >> This is a first draft, thanks in advance for feedback! >> >> >> >> - Paul >> >> _______________________________________________ >> >> swift-evolution mailing list >> >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> -Dave >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
