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