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