[swift-evolution] [Proposal] Foundation Swift Encoders

[Ben Rimmington]

> On 4 Apr 2017, at 22:43, Itai Ferber wrote:
> 
>> On 4 Apr 2017, at 1:57, Brent Royal-Gordon wrote:
>> 
>> I like the separation between keyed and unkeyed containers (and I think "unkeyed" is a good name, though not perfect), but I'm not quite happy with the unkeyed container API. Encoding a value into an unkeyed container appends it to the container's end; decoding a value from an unkeyed container removes it from the container's front. These are very important semantics that the method names in question do not imply at all.
> 
> I think that consistency of phrasing is really important here, and the action words "encode" and "decode" are even more important to connote than the semantics of pushing and popping.
> (Note that there need not be specific directionality to an unkeyed container as long as the ordering of encoded items is eventually maintained on decode.) But on a practical note, names like encodeAtEnd and decodeFromFront (or similar) don't feel like they communicate anything much more useful than the current encode/decode.

If the unkeyed containers are FIFO then I suggest:

* a `QueuedEncodingContainer` protocol with `enqueue(_:)` methods,
* a `QueuedDecodingContainer` protocol with `dequeue(_:)` methods.