On Fri, Jun 10, 2016 at 12:30 PM, let var go <letva...@gmail.com> wrote:
> I respect that anti-goal, but I think being over-rigid about limiting > developers' choice of expression is also an anti-goal. > > To me, it is like guard statements vs. if-let statements. Some people find > one to be more clear than the other. Often times the best choice depends on > the context. Sometimes a guard statement can be re-written as an if-let > statement in a way that makes the code more clear, and vice versa. > The comparison with `guard` and `if` is a little inapt. The introduction of `guard` solved a practical daily issue with `if` that was nicknamed the pyramid of doom, where successive `if let` statements caused code to be severely nested in braces and nearly unreadable. Further, you must exist the scope with `guard`; thus, its use signals an intention not possible with `if`. If, on the other hand, you do not wish to exit the scope, you must use `if`. So in a Venn diagram, there are independent uses for `if` that cannot be fulfilled by `guard`, and uses for `guard` that would be unreadable if rewritten with `if`. > And different people will inevitably have different personal preferences - > their own "style", if you will - and will favor one over the other. But it > would be a mistake to force everyone into one box in order to prevent the > fracturing of the Swift community into "dialects." > > But most importantly (and this is really the kicker for me) there are > times when the "where" syntax provides the maximum amount of clarity in the > context of my code, and I don't want to lose that expressive power. > This is the key and salient point here. Would you be able to share some examples where the `where` syntax provides a clear win in clarity? That would definitely be a huge pro, if it can be used to solve issues in expressiveness much like `guard` allowed elimination of the pyramid of doom. > > On Fri, Jun 10, 2016 at 10:17 AM Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> I think this idea--if you don't like it, then you don't have to use >> it--is indicative of a key worry here: it's inessential to the language and >> promotes dialects wherein certain people use it and others wherein they >> don't. This is an anti-goal. >> >> On Fri, Jun 10, 2016 at 12:10 let var go <letva...@gmail.com> wrote: >> >>> Leave it in! >>> >>> It's a great little tool. I don't use it very often, but when I do it is >>> because I've decided that in the context of that piece of code it does >>> exactly what I want it to do with the maximum amount of clarity. >>> >>> If you don't like it, then don't use it, but I can't see how it detracts >>> from the language at all. >>> >>> The *only* argument that I have heard for removing it is that some >>> people don't immediately intuit how to use it. I didn't have any trouble >>> with it at all. It follows one of the most basic programming patterns ever: >>> "For all x in X, if predicate P is true, do something." The use of the >>> keyword "where" makes perfect sense in that context, and when I read it out >>> loud, it sounds natural: "For all x in X where P, do something." That is an >>> elegant, succinct, and clear way of stating exactly what I want my program >>> to do. >>> >>> I don't doubt that it has caused some confusion for some people, but I'm >>> not sold that that is a good enough reason to get rid of it. It seems >>> strange to get rid of a tool because not everyone understands how to use it >>> immediately, without ever having to ask a single question. As long as its >>> not a dangerous tool (and it isn't), then keep it in the workshop for those >>> times when it comes in handy. And even if there is some initial confusion, >>> it doesn't sound like it lasted that long. It's more like, "Does this work >>> like X, or does this work like Y? Let's see...oh, it works like X. Ok." >>> That's the entire learning curve...about 5 seconds of curiosity followed by >>> the blissful feeling of resolution. >>> >>> On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>>> On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>> swift-evolution@swift.org> wrote: >>>> >>>>> > And to follow-up to myself once again, I went to my "Cool 3rd Party >>>>> Swift Repos" folder and did the same search. Among the 15 repos in that >>>>> folder, a joint search returned about 650 hits on for-in (again with some >>>>> false positives) and not a single for-in-while use. >>>>> >>>>> Weird. My own Swift projects (not on Github :P) use “where” all the >>>>> time with for loops. I really like it and think it reads *and* writes far >>>>> better as well as makes for nicer one-liners. In one project, by rough >>>>> count, I have about 20 that use “where” vs. 40 in that same project not >>>>> using “where”. >>>>> >>>>> In another smaller test project, there are only 10 for loops, but even >>>>> so one still managed to use where. >>>>> >>>>> Not a lot of data without looking at even more projects, I admit, but >>>>> this seems to suggest that the usage of “where” is going to be very >>>>> developer-dependent. Perhaps there’s some factor of prior background at >>>>> work here? (I’ve done a lot of SQL in another life, for example.) >>>>> >>>> >>>> That is worrying if true, because it suggests that it's enabling >>>> 'dialects' of Swift, an explicit anti-goal of the language. >>>> >>>> >>>>> >>>>> I feel like “where” is a more declarative construct and that we should >>>>> be encouraging that way of thinking in general. When using it, it feels >>>>> like “magic” for some reason - even though there’s nothing special about >>>>> it. It feels like I’ve made the language work *for me* a little bit rather >>>>> than me having to contort my solution to the will of the language. This >>>>> may >>>>> be highly subjective. >>>>> >>>>> l8r >>>>> Sean >>>>> >>>>> _______________________________________________ >>>>> 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