OK, understood. Thanks!
Zach On Tue, Apr 4, 2017, at 05:53 PM, Itai Ferber wrote: > Hi Zach, > Thanks for your comments! > The type is called "unkeyed", but I assume "nonkeyed" was a typo and > that's what you meant. As far as the phrasing of "ordered" and > "sequential", both sound good, but: > 1. The symmetry between "keyed" and "unkeyed" is helpful in creating > opposition between types of encoding (and especially so in > comparison to "single value", which is the odd man out — and you'd > extremely rarely need to interact with it) > 2. Given something that's "x" or "not x", you'd generally gravitate > toward the thing with the more positive phrasing. As you mention, > we really want to encourage keyed containers and diminish the use > of unkeyed containers unless truly necessary, because they're > fragile. The problem is, it's much easier to use the unkeyed > containers — especially accidentally as a novice, since they're > much simpler API — and I think "ordered" and "sequential" don't go > far enough to detract from their usage. > They sound good, and in fact, too good, and we find that more negative > phrasing is helpful. > — Itai > On 3 Apr 2017, at 16:01, Zach Waldowski via swift-evolution wrote: > > >> Itai and co: >> >> This is a solid improvement. >> >> I think it's appropriate to diminish the importance of non-keyed >> containers. "Nonkeyed" as the name is pretty iffy to me, though, even >> though I admit it makes the use case pretty clear. "Ordered" or >> "Sequential" both sound fine, even for an encoder that's slot-based >> instead of NSArchiver-like model. An array is ordered but you don't >> have to traverse it in order. >> >> Best, >> Zachary Waldowski >> z...@waldowski.me >> >> >> On Mon, Apr 3, 2017, at 04:31 PM, Itai Ferber via swift- >> evolution wrote: >>> Hi everyone, >>> With feedback from swift-evolution and additional internal review, >>> we've pushed updates to this proposal, and to the Swift Encoders[1] >>> proposal. In the interest of not blowing up mail clients with the >>> full HTML again, I'll simply be linking to the swift-evolution PR >>> here[2], as well as the specific diff[3] of what's changed. >>> At a high level: >>> * The Codable protocol has been split up into Encodable and >>> Decodable >>> * String keys on CodingKey are no longer optional >>> * KeyedEncodingContainer has become >>> KeyedEncodingContainerProtocol, with a concrete type-erased >>> KeyedEncodingContainer struct to hold it >>> * Array responsibilities have been removed from >>> KeyedEncodingContainer, and have been added to a new >>> UnkeyedEncodingContainer type >>> * codingKeyContext has been renamed codingPath >>> There are some specific changes inline — I know it might be a bit of >>> a pain, but let's keep discussion here on the mailing list instead >>> of on GitHub. We'll be looking to start the official review process >>> very soon, so we're interested in any additional feedback. >>> Thanks! >>> — Itai >>> _________________________________________________ >>> 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 > Links: 1. https://github.com/apple/swift-evolution/pull/640 2. https://github.com/apple/swift-evolution/pull/639 3. https://github.com/apple/swift-evolution/pull/639/commits/d619eef9166f8b45ffac152d06376cbdab536241
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution