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@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@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> >>>> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@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 >>>> z...@waldowski.me <mailto:z...@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@swift.org <mailto:swift-evolution@swift.org>> a écrit : >>>>>> >>>>>> >>>>>>> Le 9 janv. 2018 à 06:40, Nevin Brackett-Rozinsky via swift-evolution >>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
