[swift-evolution] Possible issue with SE-0166 Swift Archival & Serialization implementation

[Itai Ferber]

Hi James,

Good catch. This is a holdover from an older version of the proposal, 
and is now a typo.
It should be `var container` — the container can be a `struct`, and 
shouldn’t require reference semantics.

— Itai

On 8 Jun 2017, at 7:51, James Froggatt via swift-evolution wrote:

> I've just been trying out the new Coding protocol, and was rather 
> surprised when trying to implement the `encode(to encoder: Encoder)` 
> method.
>
> The Swift evolution proposal provides the following example code:
>
>     public func encode(to encoder: Encoder) throws {
>         // Generic keyed encoder gives type-safe key access: cannot 
> encode with keys of the wrong type.
>         let container = encoder.container(keyedBy: CodingKeys.self)
>
>         // The encoder is generic on the key -- free key 
> autocompletion here.
>         try container.encode(latitude, forKey: .latitude)
>         try container.encode(longitude, forKey: .longitude)
>     }
>
>
> Here, container is stored as a `let` value, and uses reference 
> semantics, while the proposal also clearly lists these `encode` 
> methods as mutating. With the current implementation of the proposal, 
> the container must be stored as a `var`, which leads to code like the 
> following:
>
>     var container = encoder.singleValueContainer()
>     try container.encode(data)
>
> This clearly wont work as expected if the container were to have value 
> semantics, and writing code like this feels plain wrong. Is SE-0166 
> really intended to work with referrence-type encoders only?
> _______________________________________________
> 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/20170608/efadf7bd/attachment.html>