[swift-evolution] 100% bikeshed topic: DictionaryLiteral

Eneko Alonso eneko.alonso at gmail.com
Tue Jan 9 11:34:21 CST 2018


Now that I think of it, this type would be great for storing results from a SQL query run on a database, for instance.

This is a valid SQL statement:

SELECT `firstname`, `lastname`, `firstname` FROM `employees`;

Note there is two copies of “firstname”. Don’t ask why. All that matters is that is valid SQL and that storing the results on a Dictionary wouldn’t be possible without manipulation.

Thus, using DictionaryLiteral (aka TableRow) would make much sense. Users could then convert to a Dictionary with the new unifyingKeys initializer, or “deserialize” into custom models that can be initialized with the TableRow (maybe via Decodable).

Given a proper name, this type could be really useful in many cases.

Thanks,
Eneko


> On Jan 9, 2018, at 9:28 AM, Eneko Alonso via swift-evolution <swift-evolution at swift.org> wrote:
> 
> How about renaming DictionaryLiteral to Row, TabularRow or TableRow?
> 
> I think most developers are familiar with the idea that a table row contains multiple columns (in specific order), and each column has a name and a value (key/value).
> 
> Some other name suggestions:
> - Record (kind of an old name for table rows)
> - SortedDictionary (sorted dictionaries are missing on the standard library, and could give a chance to make this type more widely used)
> 
> 
> Thanks,
> Eneko 
> 
> 
> 
> 
>> On Jan 9, 2018, at 9:19 AM, Nate Cook via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution <swift-evolution at swift.org <mailto: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>
>> _______________________________________________
>> 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
> 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/9214aabc/attachment.html>


More information about the swift-evolution mailing list