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<T>` is `Codable` if and
only if `T` is `Codable`).
These collections unconditionally conform to `Codable` and trap at
runtime if the type is not actually `Codable`. The synthesis complaint
is an explicit check in the compiler so we don’t go ahead and happily
synthesize code on your behalf that would just trap at runtime.
When the conditional conformance feature lands, `[String : Any]() is
Codable` should return `false`.
On 19 Oct 2017, at 14:15, Kevin Nattinger wrote:
So, what I see as the problem here is contradictory compiler
statements:
MyPlayground.playground:5:9: note: cannot automatically synthesize
'Encodable' because '[String : Any]' does not conform to 'Encodable'
let someDict: [String : Any]
^
warning: MyPlayground.playground:8:18: warning: 'is' test is always
true
[String : Any]() is Codable
^
So is it codable or isn't it? You can use a [String: Any] in encode()
and decode() directly, so why doesn't it get compiler support? At the
least, the message needs to be updated to something that's actually
true.
On Oct 19, 2017, at 1:38 PM, David Sweeris via swift-users
<swift-users@swift.org> wrote:
Oh! Yeah, my bad... You are correct; I'd started thinking like I was
on -evolution instead of -users.
On Oct 19, 2017, at 1:29 PM, Itai Ferber <ifer...@apple.com
<mailto:ifer...@apple.com>> wrote:
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, David Sweeris wrote:
I think if you can figure that out, you’re halfway to letting
protocols conform to themselves.
(Syntactically, I would probably say that something like
“Codable.Self” would read well, but I think that already means
something. Maybe the answer will become clearer when we rework the
reflection APIs?)
Sent from my iPhone
On Oct 19, 2017, at 13:13, Itai Ferber <ifer...@apple.com
<mailto:ifer...@apple.com>> wrote:
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 necessarily a good answer.)
On 19 Oct 2017, at 12:57, David Sweeris wrote:
On Oct 19, 2017, at 12:50 PM, David Baraff via swift-users
<swift-users@swift.org <mailto:swift-users@swift.org>> wrote:
Yes; this is a case where anywhere in the code base I want to just
say
struct MyNewType : Codable {
// add codable datatypes
}
and don’t want/can’t always go to the centralized place to add
it in.
Is there some extension-like trick I can pull off that lets me
spread the implementation out over different files/libraries?
Ah, ok.
No, I don't think you'll be able to do that until/unless Swift gets
more macro/metaprogramming features. Maybe if protocols ever get to
conform to themselves? That's a common request, but implementing it
is apparently beyond tricky. I'm pretty sure somebody's working on
it, but "bigger fish" and all that...
- Dave Sweeris
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
