<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div>First, let me say that basic premise was intended to be “I would like the ability to have a protocol for dictionary-type objects rather than have it be a single implementation for several reasons, but I expect that there would also be several hurdles to doing so”. It is more of an idea than a design or proposal at this point, partly because I suspect some of the hurdles may either be blocking until other enhancements land in Swift, or that having a concrete dictionary type is just preferred based on the design goals of the language. </div><div><br class=""></div><div>My interface was just a copying of the methods on Dictionary which I thought made sense for illustration purposes.</div><div class=""><br class=""></div><div class=""><rest inlnine></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 31, 2015, at 2:27 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Dec 31, 2015, at 11:17 AM, David Waite <<a href="mailto:david@alkaline-solutions.com" class="">david@alkaline-solutions.com</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">An AssociativeCollectionType would allow for alternate implementations from Dictionary, which provide space optimization, lookup performance, and functionality, to be used closer to the level of first-class citizenship that Dictionary has.</div></div></div></div></blockquote><div class="">That’s pretty abstract. Note also that one shouldn’t design protocols without a batch of concrete models that you can examine to see how they should conform.</div></div></div></blockquote><div><br class=""></div></div><div>Languages like Java and C# which are interface heavy come with a wide assortment of collections implementations, and third party implementations of even more. I’ve implemented core collection types (in Mono) and several of my own custom implementations over the years in these languages. </div><div><br class=""></div><div>And yes, I would expect design and implementation to go hand-in-hand for just about any collections changes - although the current process for swift evolution does not integrate as well as I personally would like with iterative or prototype-driven design, that would be my personal preferred approach for any larger feature, especially one impacting the collections portion of the standard library.</div><div><br class=""></div><div><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">Some of this though is that many CollectionType and SequenceType operations are useful when considering a Dictionary as a sequence in a functional style - but is not the default way I at least think of Dictionaries. For instance, how often will people want to filter a dictionary into a tuple array, vs mutating or forming a new dictionary with predicate-failing entries removed?</div></div><div class=""><br class=""></div><div class=""><div class="">As least in my personal experience, the difference in relationship between Array and CollectionType (Array being a type of collection) and Dictionary and CollectionType (dictionaries can be represented by a collection) is a constant source of confusion. </div></div></div></div></blockquote><div class=""><br class=""></div>That sounds like a different issue. Are you suggesting dictionaries should have-a collection rather than be-a collection?</div></blockquote><div><br class=""></div>Oh boy. Prefacing with “I am unsure if I want to get into that conversation due to the impact being too great for any bike shedding to ever be relevant”, mostly yes. If it is worth further discussion, it is probably worth doing so in a separate thread.</div><div><br class=""></div><div>A Dictionary is as representable as a collection as a Set would be. The underlying implementation of both both could just as well be an array of optionals (I’ve implemented one as such).</div><div><br class=""></div><div>However, there is a pattern in Swift collections of pushing down as much default implementation as possible balanced against the expense of a naive default implementation. As such, there is a complexity imported directly into Dictionary to deal with what I perceive as a secondary representation of the information in the dictionary - a list of key, value pairs.</div><div><br class=""></div><div><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Some the cons I’ve identified:</div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">- Protocols today do not have generic arguments, making any function declaration wanting to take “any string to string associative collection” vs “[String:String]” be significantly more complex.</div></blockquote></div></div></blockquote><div class=""><br class=""></div>I don’t see why you think that increases complexity. I don’t agree that it does. This also seems like a completely separate issue from whether we have AssociativeCollection.</div></blockquote><div><br class=""></div><div>I was speaking to the declarative complexity and verbosity in today’s syntax:</div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>func process(data:[String:String]) </div><div>vs.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func process<ACT:AssociativeCollectionType where ACT.Key == String, ACT.Value == String>(data:ACT)</div><div><br class=""></div><div>This would make it very difficult for one to have a custom implementation of an associative collection which accepted by third party code, simply because the API designers went with the simpler, more readable syntax.</div><div><br class=""></div><div><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><br class=""></div><div class="">- It is more pragmatic and simpler from a type perspective to push code to use a single Array or Dictionary implementation rather than needing to support generic implementations, except when opted into. This is similar to the use of lazy, or the use of Int vs smaller or more specific types.</div></blockquote></div></div></blockquote><div class=""><br class=""></div>True, and it will always be that way AFAICT. And again this seems like a completely separate issue.</div></blockquote><div><br class=""></div><div>I don’t know if it is an issue - it may very well be an explicit design goal to reduce decisions around types. I say that it *may* be an explicit design goal, because some of the cases cited may indeed be the result of the featureset of the current language.</div><div><br class=""></div><div>I can’t say if the push toward using Int for everything would be lessened with an updated numerics system, or if operations like map return arrays rather than a new sequence because of current limitations in the generics system - I simply don’t know.</div><br class=""></div><div>-DW</div></body></html>