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

[Zach Waldowski]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170403/ed2e83c2/attachment.html>