[swift-evolution] [Draft] Dictionary & Set Enhancements

[Jason Gregori]

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 <swift-evolution at swift.org> 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
>   zach at waldowski.me
> 
> 
>> 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 <swift-evolution at swift.org> 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
>>   zach at waldowski.me
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170403/f259cfd5/attachment.html>