[swift-evolution] 100% bikeshed topic: DictionaryLiteral

Gwendal Roué gwendal.roue at gmail.com
Tue Jan 9 01:12:38 CST 2018

> Le 9 janv. 2018 à 08:06, Gwendal Roué via swift-evolution <swift-evolution at swift.org> a écrit :
>> Le 9 janv. 2018 à 06:40, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> The ulterior question of whether preserving “DictionaryLiteral” is worthwhile, is apparently out of scope. Personally, I have a hard time imagining a compelling use-case outside of the standard library, and I doubt it’s being used “in the wild” (I checked several projects in the source-compatibility suite and found zero occurrences).
> DictionaryLiteral is worthwhile. The SQLite library GRDB uses DictionaryLiteral in order to build database rows (which may have duplicated column names, and whose column ordering is important). This is mostly useful for tests:
>     let row = try Row.fetchOne(db, "SELECT 1 AS a, 2 AS a")!
>     XCTAssertEqual(row, ["a": 1, "a": 2])
> Gwendal

Chris Lattner's wrote:

> why is maintaining duplicate keys a feature?

> Since it is immutable, why not sort the keys in the initializer, allowing an efficient binary search to look up values?

I really wish both duplicated keys and key ordering would be preserved, since both are needed for the above sample code.

Should those features be lost, the sky wouldn't fall, that's sure. But we'd have to write something much less easy to wrote and read:

	XCTAssertEqual(row.map { $0 }, [("a", 1), ("a", 2)])


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

More information about the swift-evolution mailing list