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
[email protected]
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
[email protected]
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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
