> * What is your evaluation of the proposal? -1. It removes a useful feature. Swift 3 has already removed enough and the argument in this case feels pretty weak to me.
I have no doubt that *some* people are confused by this feature, but that will be the case for any feature. This feature is very similar to features in many other languages. The potential for confusion here seems pretty low for anyone familiar with SQL, list comprehensions, etc. Those who aren’t familiar with this construct may be delighted once they learn how it works. If this was an entirely novel programming language feature I might be more sympathetic to the learnability / potential for confusion argument, but it isn’t and the argument in this case is weak IMO. The style argument is also weak. The Swift compiler is *not* the right place to enforce style. Other proposals attempting to enforce style rules have been rejected and this one should as well. The argument that `guard` is a more complete replacement is true, but it also completely disregards the fact that filtering is by far the most commonly desired behavior. Swift embraces syntactic sugar for common cases in many places. In that respect this feature fits the language very well. Moving the condition into the loop and requiring explicit control flow is significantly *less* clear and readable IMO. The argument that this feature is not commonly used only considers a relatively small amount of code in very specific domains. It does not provide any analysis of *why* this might be the case. The findings could be due to the domains in question or stylistic preferences of the authors of the code in question. I’ll concede that the authors of the standard library and Carthage are probably familiar with this feature, but outside of this context the feature may still be relatively unknown. Removing a feature on grounds that it is not commonly used without an analysis of *why* is a bad idea, especially in a relatively new language like Swift where many programmers it is targeting are just starting to learn the language. Finally, I think “breakage fatigue” in Swift 3 is a valid concern. We are making major changes and removing several conveniences. We should not do this more than necessary. This change does not feel necessary. It may be possible to improve this feature or replace it with something more powerful down the road, but we should not speculatively remove it now on grounds that we might do that later. > * Is the problem being addressed significant enough to warrant a change > to Swift? No. > * Does this proposal fit well with the feel and direction of Swift? No. It removes a very Swifty (IMO) convenience feature without a compelling reason to do so. > * If you have used other languages or libraries with a similar feature, > how do you feel that this proposal compares to those? I have used languages both with and without features similar to `for in where`. This is a very nice feature in languages that have it. I would be disappointed to see Swift remove it without replacing it with something more powerful. > * How much effort did you put into your review? A glance, a quick > reading, or an in-depth study? I followed the discussion thread, read the proposal, read the reviews, etc. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
