[swift-evolution] [Proposal] Foundation Swift Archival & Serialization
zach at waldowski.me
Tue Apr 4 17:00:31 CDT 2017
OK, understood. Thanks!
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.
>> Zachary Waldowski
>> zach at 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
>>> 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, as well as the specific diff of what's changed.
>>> At a high level:
>>> * The Codable protocol has been split up into Encodable and
>>> * 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.
>>> — Itai
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution