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

[Zach Waldowski]

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

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

>> 

>> 

> _______________________________________________

>  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170404/b47af7df/attachment.html>