[swift-evolution] for-else syntax

[Erica Sadun]

I'm not really seeing the advantage of `for item in collection else` being discussed or a compelling use case that motivates a language change.

You can check the empty case first for empty collections:

if collection.isEmpty {
    ...
} else for item in collection {
    ...
}

If you're filtering while iterating, you can use an access counter, for what is surely an uncommon test, or better yet, filter first and use the leading isEmpty test:

var access = 0
for item in collection where condition {
    access += 1
}
if access == 0 {
}

It seems to me that the only reason the language should change would be to handle abnormal loop processing, such as a break, but then why not throw an error and embed the for-loop in a do-catch? And honestly, I don't really think I'd ever use this or could think of a scenario where I'd need this.

-- E


> On Feb 3, 2017, at 10:01 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I would prefer `ifNone:` instead of `otherwise` as it makes the semantics clearer IMHO.
> 
> -Thorsten 
> 
> Am 03.02.2017 um 12:50 schrieb Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
> 
>> 
>>> On 2 Feb 2017, at 13:44, Derrick Ho <wh1pch81n at gmail.com <mailto:wh1pch81n at gmail.com>> wrote:
>>> 
>>> Maybe we can add a new parameter "otherwise" to the forEach method
>>> 
>>> [1,2,3,4].forEach({
>>> // do something
>>> }
>>> , otherwise: {
>>> // do something if it is an empty array
>>> })
>> 
>> That could be a decent compromise; just tried a simple extension and the following seems to work quite nicely:
>> 
>> extension Sequence {
>> 	func forEach(_ body: (Iterator.Element) throws -> Void, otherwise: () throws -> Void) rethrows -> Void {
>> 		var it = self.makeIterator()
>> 		if let first = it.next() {
>> 			try body(first)
>> 			while let current = it.next() { try body(current) }
>> 		} else { try otherwise() }
>> 	}
>> }
>> 
>> let names = ["foo", "bar", "baz"], empty:[String] = []
>> names.forEach({ print($0) }, otherwise: { print("no names") })
>> empty.forEach({ print($0) }, otherwise: { print("no names") })
>> 
>> Of course it lacks the ability to use continue or break, so the question is; does it add enough utility to add, or is it better left to developers to extend themselves?
>> 
>>> On Thu, Feb 2, 2017 at 6:31 AM Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> I'm of two minds on this feature; I kind of support the idea of the construct, especially because there are some behind the scenes optimisations it can do, and it can look neater.
>>> However, I'm not at all keen on the re-use of else; if there were a better keyword I might suppose that, for example "empty" or something like that, but nothing I can think of feels quite right.
>>> 
>>> I mean, when it comes down to it the "best" way to write the loop is like:
>>> 
>>> var it = names.makeIterator()
>>> if let first = it.next() {
>>> 	print(first)
>>> 	while let current = it.next() { print(current) }
>>> } else { print("no names") }
>>> 
>>> However this is a horrible thing to do in your own code, especially if the loop body is larger than one line, but is just fine if it's done behind the scenes for you (complete with unwrapping of the iterators if their type is known).
>>> 
>>> Which is why I kind of like the idea of having the construct itself; otherwise, like others, I use the less "correct" option like so (for sequences):
>>> 
>>> var empty = true
>>> for name in names { print(name); empty = false }
>>> if empty { print("no names") }
>>> 
>>> At which point I simply hope that the compiler optimises away the assignment (since it only actually does something on the first pass).
>>> 
>>> So yeah, I can see a use for it, but I'd prefer a construct other than for/else to do it; at the very least a different keyword, as there's the possibility we could also have a while/else as well and it would need to be very clear, which I don't feel that for/else is.
>>> 
>>>> On 2 Feb 2017, at 11:06, Jeremy Pereira via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> 
>>>>> On 1 Feb 2017, at 18:29, Chris Davis via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> ah! I forgot about the break semantics, that’s definitely one for the con list.
>>>>> 
>>>>> I like Nicolas’ solution, clear to read.
>>>>> 
>>>>>> On 1 Feb 2017, at 18:18, Nicolas Fezans <nicolas.fezans at gmail.com <mailto:nicolas.fezans at gmail.com>> wrote:
>>>>>> 
>>>>>> I tend to write this kind of treatment the other way around...
>>>>>> 
>>>>>> if names.isEmpty {
>>>>>> 	// do whatever
>>>>>> } // on other cases I might have a few else-if to treat other cases that need special treament
>>>>>> else {
>>>>>> 	for name in names {
>>>>>> 		// do your thing
>>>>>> 	}
>>>>>> }
>>>>>> 
>>>> 
>>>> 
>>>> This only works if you know the size of the sequence before you start iterating it. You can, for example, iterate a lazy sequence and calculating its size before iterating it defeats the object.Thus for { … } else { … } where the else block only executes if the for block was never executed does have some utility.
>>>> 
>>>> However, I am not in favour adding it. The same functionality can be achieved by counting the number of iterations and testing the count afterwards (or by using a boolean). It takes a couple of extra lines of code and an extra variable, but I think that is a Good Thing. It’s more explicit and (as the Python example shows) there could be hidden subtleties that confuse people if for … else … is badly designed. Also, in many cases, I would argue that treating the zero element sequence differently to the n > 0 element sequence is a code smell. About the only use-case I can think of off the top of my head is UI presentation e.g. “your search didn’t return any results” instead of a blank page.
>>>> 
>>>> Talking of Python, Swift is not Python and the argument not to implement a feature because its semantics conflict with the semantics of a similar looking feature in another language is bogus. I don’t see the Python for … else being different (and having looked it up to see what you all were talking about, my opinion is that the Python for … else is a disaster) as being a legitimate con to this cleaner and more logical idea in Swift.
>>>> 
>>>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <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 <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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170203/421bca9b/attachment.html>