Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review manager directly, please keep the proposal link at the top of the message.
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
As ever, your contributions to the review process are greatly appreciated.
I'm very much in favor of this rename. To see why, just browse through the original pitch and see how many times participants in the thread were confused about the difference between "dictionary literals" and DictionaryLiteral. I recommend against turning that into a drinking game, on health grounds.
In that pitch, the alternative suggestion was to eliminate it. I think there's a clear place for a static dictionary-literal-expressible type that preserves order and allows duplicate keys. Mirror uses it for good reason, as it's a good way of enabling APIs that take key-value arguments where position matters and duplicates are allowed, and I've used it in similar places in other code in the past.
I must admit that I haven't followed the bikeshedding thread and therefore I don't know if the names were considered there or not, but personally I do not like the List suffix since it would be a little confusing with an actual List type (which Swift does not have because it prefers Arrays). So I want to put this two possibilities for consideration.
The current name is in my opinion the most poorly-named thing in the history of Swift's standard library (and there have been a number of bad names in past versions of Swift). It's probably the single most confusing thing in all of Swift.
The functionality is potentially useful in a number of use cases beyond Mirror (as pointed out in the dynamically callable types proposal) so keeping it in the standard library seems like a good idea, as long as the name changes.
I'm not too particular about the exact name. KeyValueList seems reasonable, but KeyValueArray or similar would be also fine. I like KeyValuePairs
+1. Except a caveat about the naming. Read the caveat under "feel and direction of Swift".
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, the existing name is confusing.
Does this proposal fit well with the feel and direction of Swift?
Yes, with one caveat:
So far, the use of "List" in standard library is limited to C va_list and otherwise unprecedented. Some suggested alternatives such as Pairs are also unprecedented.
Since List is a common name in many programming languages and means different things in different languages, I am concerned that this naming choice might have unintended consequences down the road.
I don't like the suggested Array substitute, because it has a very specific and narrow meaning in Swift which does not apply to this type.
What should we call such specialized collections? Is this going to be the last of them?
This name selection have consequences beyond the narrow scope of this proposal: Are we introducing/approving List as the word to describe such types?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
n/a
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Have been participating on the topic since the original pitch.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes.
Does this proposal fit well with the feel and direction of Swift?
Yes, but like many others, I'm not sure the unprecedented name "List" is the best direction.
I like KeyValuePairs or KeyValuePairCollection. There are struct precedents for these kinds of names: DefaultIndices (plural noun), and FlattenCollection (noun ending with "Collection").
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I haven't, but I consider today's DictionaryLiteral a very useful feature for DSLs.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Would you mind elaborating? As I understand it, DictionaryLiteral is ordered and has sequential, 0-based indices, so it seems fairly Array-like to me.
Though, now that I actually poke around at it, I realise that it's not mutable for some reason. Is there a good reason why it doesn't conform to MutableCollection and similar? It seems like it should easily be able to support all the standard Array features. If it did, then KeyValueArray seems like a better name for it, but it it doesn't then perhaps the name should reflect the immutability somehow. I agree with everyone else asking for the definition of what List would mean in Swift, if the proposed name is accepted.
I think KeyValueList is an appropriate name and would remove much confusion. Reading KeyValuePairs, I imagine the contents of a collection, rather than a container: A KeyValueList contains KeyValuePairs. I'm probably way off there
A rename is a very good idea. I prefer KeyValueArray because it describes the type’s performance characteristics more specifically, but KeyValueList is fine too.
By the way, I’ve used this type recently and it’s very handy. I’m glad that it exists.
Given that you used the type, how could you suggest it be improved preferably without many API changes beyond say, enhancing subscripting? Improved for performance? Improved for conformance?
Soft +1. Don't really like either the present name because it isn't a dictionary or a literal and don't really like the proposed name because List has no precedent in Swift and carries baggage from other languages - prefer KeyValueArray.
Is the problem being addressed significant enough to warrant a change to Swift?
Marginal, its not like it is a commonly used type.
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
No
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Followed evolution discussion. Have never used the type myself.
It was perfectly fine for what I needed from it (which was pretty much to just list name-value pairs, but preserve their order so I could iterate over them in that order). If you wanted me to suggest a change, I'd say add MutableCollection and RangeReplaceableCollection conformances to make the type more useful—if it's not just a "literal" anymore, there's no reason to keep you from modifying it.
I realize that this is coming in late, but let me add some context. The only purpose this type was designed to serve was to be used as the parameter type of a method or init that accepts a dictionary literal as an actual argument, when you don't want to lose the specified syntactic order, hash the keys, allocate new storage, or even necessarily have hashable keys. In other words, it is used for its syntactic qualities. Since "dictionary literal" is the name of the syntactic element this type supports, use sites of this type name read well.
Actually, @gribozavr gave a much more complete explanation of all this in the original thread and I think if people were still confused after that, instead of reading his post they probably read the documentation for the type, which as he points out does not at all explain the type's purpose.
I can see that if you wanted to store one of these things or create it and then pass it to a method later, it might make sense to call it something else. KeyValueBuffer would not be terrible. It is like an UnsafeBufferPointer without the Unsafe part, and—since it doesn't expose reference semantics—without the Pointer part.
Correction: 2016-05-28 the following statement is wrong; it holds an array and could easily be made mutable and extended.
I wrote:
That is not possible without compromising performance. Right now it simply refers to the memory the compiler created for us and doesn't do any storage management, COW, etc.
