[swift-evolution] Add a while clause to for loops
Hignite, Jamie
Jamie.Hignite at kindred.com
Wed Jun 8 14:27:26 CDT 2016
+1 as well
Thanks!
Jamie
On 6/7/16, 7:20 AM, "swift-evolution-bounces at swift.org on behalf of
Vladimir.S via swift-evolution" <swift-evolution-bounces at swift.org on
behalf of swift-evolution at swift.org> wrote:
>My +1 to the proposal and for Charlie's opinion. I believe `while` in
>`for`
>loop would be very handy and helpful in some situations, it is a pair for
>existed `where`, its meaning is obvious, and its existence can't depend
>on
>existence of any method in collections. I'd like to see a formal proposal
>for this feature.
>
>On 07.06.2016 8:18, Charlie Monroe via swift-evolution wrote:
>> I strongly disagree.
>>
>> Exchanging
>>
>> for result in results where result.value != .Warning while result.value
>>!=
>> .Error {
>> /// ...
>> }
>>
>> for either
>>
>> for result in results.filter({ $0.value != .Warning }).prefix(while: {
>> $0.value != .Error })) {
>> /// ...
>> }
>>
>> or
>>
>> for result in results {
>> if result.value == .Warning { continue }
>> if result.value == .Error { break }
>>
>> /// ...
>> }
>>
>> Seems like an absolute step back. Not to mention filter(_:) doesn't
>>return
>> a lazy collection, but will recreate it, while the `where` will do
>> on-the-fly check.
>>
>>> On Jun 7, 2016, at 1:34 AM, Xiaodi Wu via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> Personally, given this discussion and the one about `where` in if and
>>> while statements, I would not be opposed to elimination of `where` in
>>> control statements altogether.
>>>
>>> My reasoning would be that words like filter and prefix unambiguously
>>> indicate what happens to elements of a sequence for which the predicate
>>> returns false, whereas words like where and while are ambiguous.
>>>
>>> On Mon, Jun 6, 2016 at 17:52 Tim Vermeulen <tvermeulen at me.com
>>> <mailto:tvermeulen at me.com>> wrote:
>>>
>>> I didn¹t mean we should really get rid of the `where` clause, it¹s
>>> great. I guess the point I was trying to make is that we can use a
>>> `where` clause with a `for` loop in Swift, despite the existence of
>>> the `filter` method. So despite `prefix(while:)` in Swift 3, there
>>> might be room for a `while` clause. I think it makes the code a lot
>>> more readable, much like how `where` can make a `for` loop a lot
>>>more
>>> readable than using `filter`.
>>>
>>> > The burden of proof for adding new features is different from
>>>that
>>> for taking away existing features.
>>> >
>>> > If a feature doesn't yet exist, a successful proposal will show
>>>how
>>> it provides additional and non-trivial utility. If a feature
>>>already
>>> exists, a successful proposal to remove it will show how it is
>>> harmful to the language or contrary to the direction in which it is
>>> evolving.
>>> >
>>> > On Mon, Jun 6, 2016 at 15:38 Tim Vermeulen<tvermeulen at me.com
>>> <mailto:tvermeulen at me.com>(mailto:tvermeulen at me.com
>>> <mailto:tvermeulen at me.com>)>wrote:
>>> > > The functionality of the `where` clause in `for` loops also
>>> already can be mimicked using `filter`. Wouldn¹t we have to get
>>>ride
>>> of the `where` clause by that logic?
>>> > >
>>> > > >The functionality being asked for here is already accepted for
>>> inclusion to Swift as a method on Sequence named `prefix(while:)`
>>> (SE-0045):
>>> > > >
>>> > > >`for element in array.prefix(while: { someCondition($0) }) {
>>>... }`
>>> > > >On Mon, Jun 6, 2016 at 14:31 T.J. Usiyan via
>>> swift-evolution<swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>(mailto:swift-evolution at swift.org
>>>
>>><mailto:swift-evolution at swift.org>)(mailto:swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>)>wrote:
>>> > > >>(As I said, I can live with `while`. I am simply presenting a
>>> potential point of confusion.)
>>> > > >>You aren't evaluating the statements in the loop 'while' the
>>> condition isn't met. The first time that the condition isn't met,
>>> evaluation of the loop stops. I get that this is technically true
>>>for
>>> the `while` construct but I suggest that the only reason that it
>>> works there is that 'stopping the first time that the condition
>>>isn't
>>> met' *is* the construct. Here, we have a loop that we execute for
>>> each thing and we're tacking on/intermingling the `while`
>>>construct.
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >>On Mon, Jun 6, 2016 at 2:19 PM, Thorsten
>>> Seitz<tseitz42 at icloud.com
>>> <mailto:tseitz42 at icloud.com>(mailto:tseitz42 at icloud.com
>>> <mailto:tseitz42 at icloud.com>)(mailto:tseitz42 at icloud.com
>>> <mailto:tseitz42 at icloud.com>)>wrote:
>>> > > >>>
>>> > > >>>>Am 06.06.2016 um 19:43 schrieb Tim Vermeulen via
>>> swift-evolution<swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>(mailto:swift-evolution at swift.org
>>>
>>><mailto:swift-evolution at swift.org>)(mailto:swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>)>:
>>> > > >>>>
>>> > > >>>>I also considered `until`, but it would be a bit confusing
>>> that `where` makes sure a condition is met, while `until` makes
>>>sure
>>> the condition isn¹t met. I think `while` makes more sense because
>>>it
>>> corresponds to `break` in the same way that `where` corresponds to
>>> `continue`.
>>> > > >>>
>>> > > >>>That's a good argument! The only drawback is that `while`
>>>and
>>> `where` look quite similar at a glance.
>>> > > >>>
>>> > > >>>-Thorsten
>>> > > >>>
>>> > > >>>>
>>> > > >>>>>`while`, to me, actually reads like it should do what
>>> `where` does.
>>> > > >>>>
>>> > > >>>>To me, `while` reads like it should stop the loop once the
>>> condition isn¹t met, just like in a while loop.
>>> > > >>>>
>>> > > >>>>>I hadn't thought about `while` in this regard but wouldn't
>>> `until` make more sense? `while`, to me, actually reads like it
>>> should do what `where` does. In any case, whether it is `while` or
>>> `where`, this seems like a reasonable feature in my opinion.
>>> > > >>>>>
>>> > > >>>>>TJ
>>> > > >>>>>
>>> > > >>>>>On Mon, Jun 6, 2016 at 5:15 AM, Tim Vermeulen via
>>> swift-evolution<swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>(mailto:swift-evolution at swift.org
>>>
>>><mailto:swift-evolution at swift.org>)(mailto:swift-evolution at swift.org
>>>
>>><mailto:swift-evolution at swift.org>)(mailto:swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>)>wrote:
>>> > > >>>>>>We can already use a where clause in a for loop like
>>>this:
>>> > > >>>>>>
>>> > > >>>>>>for element in array where someCondition(element) {
>>> > > >>>>>>// Š
>>> > > >>>>>>}
>>> > > >>>>>>
>>> > > >>>>>>which basically acts like
>>> > > >>>>>>
>>> > > >>>>>>for element in array {
>>> > > >>>>>>guard someCondition(element) else { continue }
>>> > > >>>>>>// Š
>>> > > >>>>>>}
>>> > > >>>>>>
>>> > > >>>>>>Sometimes you want to break out of the loop when the
>>> condition isn¹t met instead. I propose a while clause:
>>> > > >>>>>>
>>> > > >>>>>>for element in array while someCondition(element) {
>>> > > >>>>>>// Š
>>> > > >>>>>>}
>>> > > >>>>>>
>>> > > >>>>>>which would be syntactic sugar for
>>> > > >>>>>>
>>> > > >>>>>>for element in array {
>>> > > >>>>>>guard someCondition(element) else { break }
>>> > > >>>>>>Š
>>> > > >>>>>>}
>>> > > >>>>>>
>>> > > >>>>>>I can see this particularly being useful if we have a
>>> sorted array and we already know that once the condition isn¹t met,
>>> it won¹t be met either for subsequent elements. Another use case
>>> could be an infinite sequence that we want to cut off somewhere
>>> (which is simply not possible using a where clause).
>>> > > >>>>>>_______________________________________________
>>> > > >>>>>>swift-evolution mailing list
>>> > > >>>>>>swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>(mailto:swift-evolution at swift.org
>>>
>>><mailto:swift-evolution at swift.org>)(mailto:swift-evolution at swift.org
>>>
>>><mailto:swift-evolution at swift.org>)(mailto:swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>)
>>> > > >>>>>>https://lists.swift.org/mailman/listinfo/swift-evolution
>>> > > >>>>_______________________________________________
>>> > > >>>>swift-evolution mailing list
>>> > > >>>>swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>(mailto:swift-evolution at swift.org
>>>
>>><mailto:swift-evolution at swift.org>)(mailto:swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>)
>>> > > >>>>https://lists.swift.org/mailman/listinfo/swift-evolution
>>> > > >>
>>> > > >>_______________________________________________
>>> > > >>swift-evolution mailing list
>>> > > >>swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>(mailto:swift-evolution at swift.org
>>>
>>><mailto:swift-evolution at swift.org>)(mailto:swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>)
>>> > > >>https://lists.swift.org/mailman/listinfo/swift-evolution
>>> > > >
>>> > > >
>>> > > >_______________________________________________
>>> > swift-evolution mailing list
>>> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> >
>>> >
>>> >
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>_______________________________________________
>swift-evolution mailing list
>swift-evolution at swift.org
>https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list