Hi Jon,
To clarify for those wondering, this is happening because the
`doAThing()` method dispatches statically to `doSomething()` based on
`NetworkRequests`’s `T`; since `doAThing()` isn’t overridden in
`CompressedNetworkRequest`, the method is inherited directly, including
that static dispa
coming up, and the
performance overhead of JSONSerialization with JSONDecoder on top of
it will continue to leave Swift without a very performant JSON
solution.
That said, I appreciate the support given Codable on this list.
Jon
On Oct 31, 2017, at 1:07 PM, Itai Ferber via swift
Hi Evtim,
Just want to give some context for this.
This is due to the fact that `JSONEncoder` and `JSONDecoder` are
currently based on `JSONSerialization`: when you go to decode some JSON
data, the data is deserialized using `JSONSerialization`, and then
decoded into your types by `JSONDecoder
Hi Robert,
When the conditional conformance feature arrives in Swift, it will allow
us to express `extension Array : Encodable where Element : Encodable`
and `extension Array : Decodable where Element : Decodable`.
At the moment, this isn’t possible, so `Array` is unconditionally
`Codable` and
Right now, collection types in the standard library (`Array`,
`Dictionary`, and `Set`) employ a workaround for the lack of conditional
conformance, which would allow us to expose things like `extension Array
: Codable where Element : Codable` (i.e. `Array` is `Codable` if and
only if `T` is `Co
Mm, the point I’m trying to get at here is that JSON is inherently
untyped while Swift is strongly typed, and the two don’t line up.
It doesn’t really make sense to ask to decode an existential because
there’s not enough type information to influence what you get back.
On 19 Oct 2017, at 13:20,
Even then, that wouldn’t necessarily help in the general case. If you
decode `{"key" : 1}` as `[String : Codable]`, what concrete type would
`1` have? `Int`? `Double`? `Int8`? (Arguments can be made for any one of
these, but the key here is that it is inherently ambiguous and there
isn’t necess
Then no, this wouldn’t be possible unless you could somehow express
something like:
```swift
// Cribbing some C++-style syntax here
enum OneOf : Codable where T… : Codable {
cases t…(T…)
}
```
where someone would be able to express to you that they want to store a
`OneOf` through your enum
David,
Is there an issue with extending the enum as necessary with new cases to
support what you need?
```swift
enum MyType : Codable {
case int(Int)
case string(String)
case newThingy(NewThingy)
case list([MyType])
case dictionary([String : MyType])
// …
}
```
`NewTh
Hi Geordie,
Yep, that’s the difference here — you can’t decode something with
an existential type; it has to be concrete (like you’re doing).
The reason for this is that it’s simply not possible to determine what
type to decode just from the structure of the payload.
Consider the following:
Why are you stuck? I think the following matches your needs, no?
```swift
import Foundation
enum MyType : Codable, Equatable {
case int(Int)
case string(String)
case list([MyType])
case dictionary([String : MyType])
public init(from decoder: Decoder) throws {
// Can
Hi David and Geordie,
That approach won’t work — encoders and decoders only work directly
with concrete `Codable` types (e.g. `String`, `Int`, `MyFoo` [where
`MyFoo` is `Codable], etc.).
This is by design: since there is no type information stored in the JSON
payload, there isn’t necessarily a
Hi Solli,
`CodingKey` conformance for `enum`s is synthesized by the compiler given
certain rules — you can see mention of this in the [Codable
proposal](https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md)
[search for `public protocol CodingKey`]
Hi Jon,
This was a conscious choice in the API design, for three main reasons:
1. There is a big difference between the API surface exposed at the
top-level for encoding and decoding and the middle levels. A method like
`decode(_ type: T, from data: Data)` is really only appropriate at the
to
Hi Joanna,
Your example doesn’t work for a few reasons:
1. You’re getting a compiler error because of the difference between
the representation of metatypes (`Foo.Type` for some type `Foo`) of
concrete types (e.g. `String`, `Int`), and protocols (e.g.
`DefaultValueProvider`). Some of the comp
Hi Kevin,
You’re right — this is one of the limitations of the box design
here. One thing we can do is expose the underlying boxed value as a
`KeyedDecodingContainerProtocol` existential value using an accessor on
the box so you can down-cast.
However, it shouldn’t be necessary to add any me
Hi Kevin,
> On Jun 29, 2017, at 12:30 PM, Kevin Wooten via swift-users
> wrote:
>
>> Hi Jon,
>>
>> I just joined this mailing list and have tried to catch up on the
>> history of this thread, so please excuse me if I’ve missed something.
>>
>> I’m sorry the Codable API at the moment does not
Hi Jon,
I just joined this mailing list and have tried to catch up on the
history of this thread, so please excuse me if I’ve missed something.
I’m sorry the Codable API at the moment does not answer your needs —
you’re clearly not the only one who’s run into this, so let’s see
how we can wo
18 matches
Mail list logo
