[swift-evolution] 100% bikeshed topic: DictionaryLiteral

[Nate Cook]

> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> I'm not sure a valid use case by a third party makes it hold its weight for inclusion in the stdlib.
> 
> You're definitely right, and that's why I wrote with the most humble tone I could.
> 
> Yet, the design of the stdlib *requires* some speculation about use cases, and speculation is *helped* by the exposition of actual uses. I'm not sure readers of the mailing list had any idea of the use cases of the current DictionaryLiteral, and maybe I helped a little.
> 
>> Reproducing its feature set is extremely trivial, and would probably allow you to hint the implementation details better for your use case.
> 
> Please define "trivial”.
> 
> In case anybody would wonder, in the line below the `row` variable is of type Row which happens to adopt ExpressibleByDictionaryLiteral. It is not of type DictionaryLiteral. The use case here is the ability to express a row with a dictionary literal that accepts duplicated keys and preserves ordering:
> 
> 	XCTAssertEqual(row, ["a": 1, "a": 2])

That’s great! In this case you aren’t using the DictionaryLiteral type, but a “dictionary literal”, which no one is suggesting we remove. If I’m understanding what you wrote, this is another case where the terrible name is making it super hard to discuss what we’re talking about. “Dictionary literals” and the ExpressibleByDictionaryLiteral protocol are safe!

> I don't see how anything could better fit this use case than the current DictionaryLiteral. This is not *my* use case, but the use case of anyone that wants to model database rows beyond the traditional (and ill-advised) dictionary.
> 
> Some other users may come with other use cases that may also help the stdlib designers choose the best solution.
> 
> Gwendal
> 
>> 
>> Zach
>> zach at waldowski.me <mailto:zach at waldowski.me>
>> 
>> 
>> On Tue, Jan 9, 2018, at 2:12 AM, Gwendal Roué via swift-evolution wrote:
>>> 
>>>> Le 9 janv. 2018 à 08:06, Gwendal Roué via swift-evolution <swift-evolution at swift.org <mailto: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)])
>>> 
>>> Gwendal
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20180109/bf0edd97/attachment.html>