or it points to merging Future with Option/Result being completely muddied and problematic!
-
-
Replying to @Gankra_ @JakeGoulding
So why is the first better than the second? https://gist.github.com/sgrif/f967116241999765e3f46506215ad8ae …
1 reply 0 retweets 0 likes -
Replying to @sgrif @JakeGoulding
also objectively this is the best x.flatMap { (y) in do_stuff(y) .flatMap { do_more_stuff(y, $0) }}
3 replies 0 retweets 0 likes -
Replying to @Gankra_ @JakeGoulding
Also that should probably be `flattenIntoSingleLevelAfterMappingWith: (y) in ...`
2 replies 0 retweets 0 likes -
Replying to @sgrif @JakeGoulding
You're right, &x.ft_mp(&mut || {;};);; is much more information-dense
3 replies 1 retweet 2 likes -
Replying to @jckarter @JakeGoulding
Lines like https://github.com/diesel-rs/diesel/blob/master/diesel/src/query_builder/mod.rs#L106 … are my favorite... (which could have been (&**self).to_sql(out))
1 reply 0 retweets 0 likes -
self.current_header.as_ref().map(|s| &**s).unwrap_or(""); gets me every time
4 replies 0 retweets 0 likes -
Yeah, people complain about Swift having custom operators, but when the alternative is…that…
2 replies 0 retweets 0 likes -
self.current_header.as_ref().map { &**$0 } ?? ""; seems like the best Swift's current stuff gets you?
2 replies 0 retweets 0 likes -
as_ref() and &** seem like they could be implicit. Usually only one of borrow or move is possible in context…
2 replies 0 retweets 0 likes
Yes. Ironically you actually can do it specifically for `Option` but that doesn't hide the design flaw
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.