On Mon, Jun 13, 2016 at 11:41 AM, let var go <letva...@gmail.com> wrote:
> > > On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> Moreover, I should add, if your goal is to eliminate the possibility of >> continuing and breaking from inside the loop, `.forEach()` does that >> exactly, so your argument would be for the elimination of `for..in` >> altogether. >> > > I have no "goal" of eliminating the possibility of continuing or breaking > from inside the loop. In general, it is not my goal to try and control how > other people code their programs at all. I don't want to tell you that you > can't 'continue' if you want to 'continue.' > > *I am not trying to make everyone adopt my own personal coding style > and/or philosophy.* > We're not discussing style. You made a very strong claim: use of `guard...continue` leads to 'smelly' code, or in other words bad code. In other words, you claim that `guard...continue` is harmful. That is grounds for removal, and if you believe it to be true, I encourage you to propose it to the list and get feedback on that opinion. If you're saying that you simply don't prefer it for reasons of 'style,' again I emphasize that the topic at hand here is not about personal coding style. The claim we are making is that `where` is harmful. I too like it for style, and I'll be sad to see it go. But I have concluded that it must go. > There is also a big difference between 'break' and 'continue'. I am not > afraid to use 'break', and I don't consider it a code smell. It allows for > early exit from a loop based on conditions that are not always known at the > time the loop is entered. for...in loops are necessary precisely because > they allow for the early exit. > > You don't need for...in if you want to continue - you can use forEach for > that. Instead of using 'continue', you just use 'return' without doing > anything and it moves on to the next iteration. So really, the only purpose > that for...in serves that is not served by forEach is early exit. But > regardless, *even if for...in served no additional purpose that couldn't > be served by forEach, I would keep it in the language because there are > situations where I believe it is easier to read, and expressiveness and > clarity are important to me.* > > >> >> On Mon, Jun 13, 2016 at 10:55 Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >>> On Mon, Jun 13, 2016 at 10:44 AM, let var go <letva...@gmail.com> wrote: >>> >>>> I think we must be reading different discussions. >>>> >>>> What I have seen in this discussion is the following: >>>> >>>> a) The need to filter a for-in loop doesn't arise that often; but, >>>> b) When it does arise, everyone who has chimed in on this thread >>>> (except the two people who are proposing the change) thinks that the >>>> "where" clause is the clearest, most expressive way to do it. >>>> >>>> Something that would help me get on board with this change is more >>>> evidence about what kind of problems it is actually creating. >>>> >>>> As best I can tell, this proposal got started because "somewhere" some >>>> new programmers (no one knows how many) expressed some confusion (no one >>>> knows how seriously they were confused, or how long it took them to figure >>>> it out) about how the where clause worked in a for-in loop. For all we >>>> know, once they learned the way it works, they may have said, "Hey that's >>>> cool! I'm gonna use that from now on!" >>>> >>>> In other words, you seem to be talking about removing a feature that is >>>> liked by *a lot* people, based on some unsubstantiated reports of user >>>> error that may or may not have been totally unsubstantial. >>>> >>>> I don't want new programmers to be confused, either, but the "where" >>>> clause is such a basic programming construct - the keyword is new, but the >>>> idea itself is as old as programming - that I don't mind expecting new >>>> programmers to learn how to use it. The learning curve should be incredibly >>>> short - it is nothing more than a filter operation. >>>> >>>> There's something else here that is really important to me, though I >>>> don't know how others feel about it. >>>> >>>> Using the guard...continue approach that you are promoting is a code >>>> smell. It puts control-flow logic inside the for-in loop. That is something >>>> I have always tried to avoid. I know that the language allows for it, but I >>>> believe it is bad programming practice. In fact, if you get rid of the >>>> `where` keyword, I'm still not going to use guard...continue. I'll just >>>> filter the collection first and then loop it. >>>> >>> >>> This is quite the statement. It sounds like you'd be for the elimination >>> of `continue`? >>> >>> >>>> >>>> It is a code smell for the same reason that messing with the index >>>> inside a for;; loop was a code smell. I was always taught never to do this: >>>> >>>> for var i = 0; i < array.count, i++ { >>>> if iWantThisToLoopAnExtraTime { >>>> i-- >>>> } >>>> } >>>> >>>> Why? Because code like that is confusing. It becomes difficult to know >>>> how many times the loop will execute, what the looping logic is, etc. Sure, >>>> I might get away with it most of the time, but it is bad practice and there >>>> is always a better way to do what you want to do. The only thing that keeps >>>> you from the better way is laziness. >>>> >>>> The same is true (albeit to a lesser degree) for the guard...continue. >>>> It may not be as extreme, but it is still a code smell. It divides the >>>> control-flow logic into two parts - one outside the loop, and one inside >>>> the loop, and it suddenly becomes twice as easy to miss something. >>>> >>>> Using for-in-where, all of the control-flow logic is on one single >>>> line, and once it is known that "where" operates as a filter operation, it >>>> all works together in a single, harmonious statement that declares exactly >>>> what is going to happen in a way that is totally unambiguous. >>>> >>>> So by getting rid of the "where" clause, I believe that you are >>>> actually encouraging bad programming practice. Instead of encouraging the >>>> new user to learn this very simple construct that will ultimately make >>>> their code safer and more expressive without dividing their control-flow >>>> logic unnecessarily into two separate parts, you are encouraging them to >>>> just "do what they know". I think that is terrible, and you are doing them >>>> a disservice. >>>> >>>> And from a personal standpoint, you are telling me that I have to write >>>> smelly code, even though there is this perfectly good non-smelly option >>>> sitting right there, because you don't want someone else to have to learn >>>> something. >>>> >>>> On Mon, Jun 13, 2016 at 5:29 AM Xiaodi Wu <xiaodi...@gmail.com> wrote: >>>> >>>>> I think this discussion has made it pretty plain that what is claimed >>>>> to be 'so useful' is barely ever used. Moreover, it provides no >>>>> independent >>>>> uses. The point of these pitches is to sound out arguments, not, as far as >>>>> I was aware, to take a vote. >>>>> >>>>> On Mon, Jun 13, 2016 at 1:54 AM Jose Cheyo Jimenez < >>>>> ch...@masters3d.com> wrote: >>>>> >>>>>> --1 >>>>>> >>>>>> I think it would be a waste of the community's time to do a formal >>>>>> review when only two people are in favor of this removal. >>>>>> >>>>>> 'for in where' is so useful especially since we don't have for;;; >>>>>> loops anymore. I'd say leave this alone; the majority doesn't want this >>>>>> changed. >>>>>> >>>>>> >>>>>> >>>>>> On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution < >>>>>> swift-evolution@swift.org> 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 >>>>>> >>>>>>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution