<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>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.&nbsp;</div><div><br></div><div><br>On Apr 3, 2017, at 8:18 AM, Zach Waldowski via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>


<title></title>

<div style="font-family:Arial;">Right-favoring:<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">&nbsp; &nbsp; for (key, value) in rhs {<br></div>
<div style="font-family:Arial;">&nbsp; &nbsp; &nbsp; &nbsp; lhs[key] = value<br></div>
<div style="font-family:Arial;">&nbsp; &nbsp; }<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Left-favoring:<br></div>
<div style="font-family:Arial;"><div style="font-family:Arial;"><br></div>
</div>
<div style="font-family:Arial;">&nbsp; &nbsp; for (key, value) in rhs where lhs[key] == nil {<br></div>
<div style="font-family:Arial;">&nbsp; &nbsp; &nbsp; &nbsp; lhs[key] = value<br></div>
<div style="font-family:Arial;">&nbsp; &nbsp; }<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">Throws an error:<br></div>
<div style="font-family:Arial;"><div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">&nbsp; &nbsp; for (key, value) in rhs {<br></div>
</div>
<div style="font-family:Arial;">&nbsp; &nbsp; &nbsp; &nbsp; guard lhs[key] == nil else { throw Foo() }<br></div>
<div style="font-family:Arial;">&nbsp; &nbsp; &nbsp; &nbsp; lhs[key] = value<br></div>
<div style="font-family:Arial;">&nbsp; &nbsp; }<br></div>
<div style="font-family:Arial;"><div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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.<br></div>
</div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;"><div style="font-family:Arial;"><div style="font-family:Arial;">Doing these as needed yourself are not  unreasonably complex or error-prone — unlike, say, Unicode — but they _are_ pretty domain specific.<br></div>
<div style="font-family:Arial;"><div style="font-family:Arial;"><br></div>
</div>
</div>
<div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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.<br></div>
</div>
<div style="font-family:Arial;"><br></div>
<div id="sig40804545"><div class="signature"><span class="font" style="font-family:arial, sans-serif, sans-serif">Best,</span><span class="font" style="font-family:arial, sans-serif, sans-serif"></span><br></div>
<div class="signature"><span class="font" style="font-family:arial, sans-serif, sans-serif">&nbsp; Zachary Waldowski</span><span class="font" style="font-family:arial, sans-serif, sans-serif"></span><br></div>
<div class="signature"><span class="font" style="font-family:arial, sans-serif, sans-serif">&nbsp;&nbsp;</span><a href="mailto:zach@waldowski.me"><span class="font" style="font-family:arial, sans-serif, sans-serif">zach@waldowski.me</span></a><br></div>
</div>
<div><br></div>
<div><br></div>
<div>On Sat, Apr 1, 2017, at 12:01 PM, Jason Gregori via swift-evolution wrote:<br></div>
<blockquote type="cite"><div>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?&nbsp;<br></div>
<div><br></div>
<div>Nate, do you mind throwing this up in a gist or something? My email client isn't letting me see the whole thing.&nbsp;<br></div>
<div><br></div>
<div>Thanks,&nbsp;<br></div>
<div>Jason<br></div>
<div><br></div>
<div><div style="font-family:Arial;"><br></div>
<div><div>On Fri, Mar 31, 2017 at 11:52 AM Zach Waldowski via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div style="font-family:Arial;"><u></u><br></div>
<div><div style="font-family:Arial;">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.<br></div>
<div style="font-family:Arial;"><br></div>
<div style="font-family:Arial;">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. <br></div>
<div style="font-family:Arial;"><br></div>
<div><div><span class="font" style="font-family:arial, sans-serif, sans-serif">Sincerely,</span><span class="font" style="font-family:arial, sans-serif, sans-serif"></span><br></div>
<div><span class="font" style="font-family:arial, sans-serif, sans-serif">&nbsp; Zachary Waldowski</span><span class="font" style="font-family:arial, sans-serif, sans-serif"></span><br></div>
<div><span class="font" style="font-family:arial, sans-serif, sans-serif">&nbsp;&nbsp;</span><a href="mailto:zach@waldowski.me"><span class="font" style="font-family:arial, sans-serif, sans-serif">zach@waldowski.me</span></a><br></div>
</div>
<div><br></div>
</div>
<div style="font-family:Arial;">_______________________________________________<br></div>
<div style="font-family:Arial;">swift-evolution mailing list<br></div>
<div style="font-family:Arial;"><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div style="font-family:Arial;"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote></div>
</div>
<div><u>_______________________________________________</u><br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote><div style="font-family:Arial;"><br></div>


</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>