Thanks. I agree that adding first, last, and merge strategy seems like overkill. But I still really like having the merge methods. For me it's something that comes up often on almost every project I work on.
> On Apr 3, 2017, at 8:18 AM, Zach Waldowski via swift-evolution > <[email protected]> wrote: > > Right-favoring: > > for (key, value) in rhs { > lhs[key] = value > } > > Left-favoring: > > for (key, value) in rhs where lhs[key] == nil { > lhs[key] = value > } > > Throws an error: > > for (key, value) in rhs { > guard lhs[key] == nil else { throw Foo() } > lhs[key] = value > } > > The barrier to inclusion in the stdlib should not merely be if someone's had > to write it before, otherwise there's no reason not to include your > Instagram-but-for-cats client full-on in the OS. > > Doing these as needed yourself are not unreasonably complex or error-prone — > unlike, say, Unicode — but they _are_ pretty domain specific. > > I'm personally not in favor of additions to the standard library that have an > associated Options or Strategy type. "Well," you may respond, "we don't want > to add a bunch of overloads, either! That'd be confusing!" And that's exactly > what I'm getting at - either way you slice it, every addition to the stdlib > has a concrete impact on the mental model of the language. > > Moreover, I am wary of language additions that can't (or we don't want to) be > modeled in terms of Collection, because we risk limiting the growth of the > latter as we get better generics features. > > Best, > Zachary Waldowski > [email protected] > > >> On Sat, Apr 1, 2017, at 12:01 PM, Jason Gregori via swift-evolution wrote: >> I really like the merging methods and have already needed to write my own. >> Zach, do you mind showing a comparison of what you're thinking? >> >> Nate, do you mind throwing this up in a gist or something? My email client >> isn't letting me see the whole thing. >> >> Thanks, >> Jason >> >> >> On Fri, Mar 31, 2017 at 11:52 AM Zach Waldowski via swift-evolution >> <[email protected]> wrote: >> >> Snipped quoted proposal so as to not break the mailing list… By and large, >> I'm in favor. I like the potential for bringing up Dictionary and Set up to >> the implementation quality of Array and String. >> >> I don't think `init(merging:resolvingCollisionsWith:)` et al hold their >> weight for inclusion in the language, unless some notable optimization >> opportunity can be surfaced out of it. Users frustrated at the lack of a >> `merge` in Swift want it to be opinionated and "just do the right thing," >> i.e., the same way as whatever other language they most recently used. A >> properly annotated and indented-to-be-beautiful use of the closure-based >> version will take up the same amount of code as doing the merge by hand with >> your custom condition. >> >> Sincerely, >> Zachary Waldowski >> [email protected] >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
