[swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Itai Ferber]

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
>
>   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[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 at 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 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/20170404/b25f8e54/attachment.html>