[swift-evolution] Remove forEach?
Jordan Rose
jordan_rose at apple.com
Tue Dec 8 18:17:56 CST 2015
This falls out of the rule that single-expression closures have their types inferred, and that that inference includes coercion to a Void return type. That's because of code like this:
dispatch_sync(queue) {
doSomeWork() // returns Bool, but I'm ignoring the result
}
Normally, the closure being passed to dispatch_sync would have an inferred type of '() -> Bool', but dispatch_sync expects a dispatch_block_t, which is '() -> Void'. You can "fix" this by explicitly ignoring the result ("_ = doSomeWork()"), but that's a little silly, so we added a rule that it's okay to ignore the result if the closure's supposed to return Void. That rule really shouldn't apply when the user explicitly wrote a return, though.
Jordan
> On Dec 8, 2015, at 15:55, Tyler Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
>
> Why does that function even compile? For example, the following produces the compiler error: Unexpected non-void return value in void function
>
> [1,2,3,4,5].forEach { x in
> let y = 0
> return x
> }
>
> Which is what I would expect. But this compiles just fine:
>
> [1,2,3,4,5].forEach { x in
> return x
> }
>
> Is this just a compiler bug, or am I missing something?
>
> Tyler
>
>> On Dec 8, 2015, at 2:18 PM, André Videla via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> Hi,
>>
>> As I understand it, the argument for remove forEach is that it’s easy to make confusing code that doesn’t do what it looks like it should do.
>>
>> In this particular example:
>>
>> func indexOf_foreach(element: Element) -> Int? {
>> self.indices.filter { idx in self[idx] == element }.forEach { idx in
>> return idx
>> }
>> return nil
>> }
>>
>> I think the compiler should give us two warnings:
>> - closure returns type Int when it should return type ()
>> - function always return nil (which is a unit type just like () ) when it expects Option<Int>
>>
>> In my opinion those warnings should be enough to make the programmer aware that this code doesn’t do what it looks like it does. Typically, returning a type when () is expected shouldn’t go silently.
>>
>> As such I think keeping forEach is important as it allows for every elegant expressions and convey already the already established convention when you use forEach that “I”m only interested in side-effects with elements in this collection”
>>
>> My proposition is then that instead of removing forEach, we should have better type check and warn when the cardinality of the expected type and the returned type don’t match.
>>
>> -André
>>
>>> On 08 Dec 2015, at 20:07, Chris Eidhof via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>
>>> Hi all,
>>>
>>> As long as the `for` loop is in the language, I don’t really see the use of `forEach`. I understand that it can read much nicer to write something like `a.map { something }.filter { somethingElse }.forEach {` rather than a `for` loop. However, I think the costs don’t outweigh the benefits. It might look like a for loop can just be replaced by a `forEach`, however, this is not true in the general case. For example, consider the following example:
>>>
>>> func indexOf_foreach(element: Element) -> Int? {
>>> self.indices.filter { idx in self[idx] == element }.forEach { idx in
>>> return idx
>>> }
>>> return nil
>>> }
>>>
>>> The code above (I realise it’s quite inefficient) might look like it’s returning the first index for which the filter’s condition returned true. However, the first occurrence of return is actually returning inside the closure, not the outer function. So the result of this function is always nil.
>>>
>>> Another solution would be to give a good warning/error message here (you’re trying to return an Optional value where we expect a ()). However, this is also problematic when dealing with side-effects. For example:
>>>
>>> [1,2,3,4,5].forEach { num in
>>> print(num)
>>> if num > 3 { return }
>>> }
>>>
>>> I think it’s quite easy to get things wrong with forEach, so I’d propose removing it and rather having a regular for loop. (Erica-style).
>>>
>>> Chris
>>>
>>> _______________________________________________
>>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151208/c1afccd3/attachment.html>
More information about the swift-evolution
mailing list