[swift-users] dealing with heterogenous lists/dictionary with Codable

[Itai Ferber]

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 at 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 <iferber at apple.com 
>>> <mailto:iferber at 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 <iferber at apple.com 
>>> <mailto:iferber at 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 at swift.org <mailto:swift-users at 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20171019/2131a38f/attachment.html>