On 28 Jul 2016, at 22:55, Rick Mann via swift-users
wrote:
> I often call methods that return an optional collection.
Why do these methods return an optional collection rather an empty collection?
Back in the day Cocoa code used to work that way because constructing
Like Rick, I had also wondered about a simple way to do this. Perhaps this is a
question for swift-evolution, but wouldn’t it be desirable if Swift supported:
for item in someOptionalContainer?
{
}
which seems more natural and intuitive that the alternatives that have been
suggested.
Kerry
You can try container?.forEach(), like
let bb:[String:Int]? = ["aa":1, "bb":2, "cc":3]
bb?.forEach { print($0) }
/*
("aa", 1)
("bb", 2)
("cc", 3)
*/
Zhaoxin
On Fri, Jul 29, 2016 at 6:14 AM, Saagar Jha via swift-users <
swift-users@swift.org> wrote:
> The nil check and creating an empty
The nil check and creating an empty array have very similar performance, in my
naïve testing.
Saagar Jha
> On Jul 28, 2016, at 14:59, Jacob Bandes-Storch via swift-users
> wrote:
>
> You should test it out — I'd guess there's a good chance it gets optimized
> out.
You should test it out — I'd guess there's a good chance it gets optimized
out.
On Thu, Jul 28, 2016 at 2:58 PM Rick Mann wrote:
> Yeah, I suppose that works. Feels a bit clunky, like the language lacks
> specific support for this (in that it provides specific support for
Yeah, I suppose that works. Feels a bit clunky, like the language lacks
specific support for this (in that it provides specific support for so many
other common constructs). But I guess I can make do with that.
I suppose there's a bit of a performance hit, in that constructing an empty
array
How about "for item in someOptionalContainer ?? []" ?
On Thu, Jul 28, 2016 at 2:55 PM, Rick Mann via swift-users <
swift-users@swift.org> wrote:
> I often call methods that return an optional collection. I then iterate
> over it. The problem is, it's a bit cumbersome to write:
>
> if let