There are cases where Dictionary is not good enough, being the most notorious one the case where the order of keys is important and should be preserved.
A good example of this are .xib and .storyboard files, where XML nodes have attributes defined in a very specific order (defined by Xcode on write). Currently there is no way to parse the XML using XMLParser while preserving the order of the attributes.
To clarify, Xcode itself does not seem to care about the order of the attributes when loading these files, but seems to write the attributes always in a specific order. Code diffs, in the other hand, quickly become burdensome when the order of XML node attributes is not preserved.
There are probably other methods, or areas where DictionaryLiteralKeyValuePairs could be used instead of a Dictionary. If this pitch were to move forward, those methods should be listed in the proposal.
Is this a type that should be used in API surface? It seemed to me that it was just a type "for the language" in order to capture what is defined with a dictionary literal. In any case it would be nice to have APIs that preserved that order (sometimes is even desirable with JSONs of some web APIs we have to deal with).
@Alejandro_Martinez correct, DictionaryLiteral is a public type in the swift standard library and as such, it can be used by types defined in the stdlib and other frameworks, like Foundation.
KeyValuePairs is like StaticString—you can't construct one at runtime—so this API could not use it. NSXMLParser could, of course, define a custom type, or simply pass an array like [(name: String, value: String)].
I'd be against this, XML attributes have no defined order and an application that relied on the order to interpret the meaning would be broken, but such application would start appearing if the order could be relied on.
Changing an API just because it would make diffing with a line by line comparison tool a bit harder seems wrong to me. There are alternatives like using an XML diff utility (the proper tool for the job) or just making sure you always write the attributes in a deterministic order (as Xcode does). You could, for instance, just sort the keys alphabetically before writing them.
@jeremyp you would be surprised how much Xcode relies on maintaining a fixed order for XMLNode attributes. From Xib and Storyboards to project and workspace files.
Think about it, it would be a total nightmare if every time you saved one of those files, the attributes where written in a different order. The amount of unnecessary changes tracked by git, and the additional amount of merge conflicts would be unbearable.
While semantically the order of XML node attributes is not important, the reality is that many applications that use XML depend one way or another in supporting a predefined order for them.
If Xcode fails to read a xib file correctly when element attributes are not in a specific order, then that is a bug in Xcode. In any case, I do not believe it is true, you yourself have said:
So now we are basing the XML parsing API on another broken tool. XML files are not line oriented text files. There are many ways of formatting an XML file that leave the logical meaning of the content unchanged and that would be problematic for line oriented diffing tools.
Having said that, there is nothing in the XML spec that says an application can't write XML files with the attributes in a deterministic order e.g. alphabetically by key.
I seriously doubt that. I have dealt with many applications that read XML files and never come across one that required the attributes to be in a certain order when it reads XML files. I suspect that is at least partly due to the fact that none of the common APIs give you any idea of what order the attributes were parsed in.
The problem described in my post above is that, when using Foundation’s XMLParser to read XML, the order of attributes is lost because XMLParserDelegate passes them as a [String: String] dictionary.
This prevents any consuming applications from being able to serialize back that XML while maintaining attributes in the same order.
It’s not a matter of wether applications are “broken” or not, that is a personal opinion.
It is a matter of information being lost by the parser.
PS: To the Swift community: if there is a better way to submit a request to the Foundation team, please let me know. Thank you.
No it doesn't. It only matters when you are using non XML aware tools such as line based comparison tools.
You're talking about the XML declaration, it's not a tag. You don't even see that if you are using XMLParser.
Consuming applications are free to serialise attributes in any order they like. As I said before, they could use alphabetical order or they could have a predefined order of writing. What they are not allowed to do is assume any significance in the order when reading XML documents.
No, it is not a personal opinion. Any application that infers any meaning from the ordering of the attributes is broken.
There is no information inherent in the ordering of XML attributes. The current use of a Dictionary models the semantics of XML attributes perfectly. Using a different model that implies an ordering to the attributes would be misleading to developers.
Can you use the XMLDocument class, instead of the XMLParser class? It's available in swift-corelibs-foundation and on macOS (but not iOS, tvOS, or watchOS).
Unfortunately libxml2 (which XMLParser uses) does not guarantee attribute order either, which is indeed perfectly valid for it to do according to the spec. In practice I believe it's currently implemented to report attributes in order and namespaces not in order, but it seems unwise to try to rely on or guarantee that particular oddity.