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> 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
