I think this is a bad idea.
I’ve worked with APIs like this in Perl, Ruby, and Obj-C. Even in a dynamic
language, IMO it’s almost always a mistake to use them. It makes code harder to
reason about when reading and debugging.
This seems especially true with Swift because you can no longer autoc
💯
> On Jun 7, 2017, at 10:35 AM, Adam Sharp via swift-evolution
> wrote:
>
> The new smart key path feature is really lovely, and feels like a great
> addition to Swift.
>
> It seems like it might be straightforward to add overloads of `map` and
> `flatMap` to the standard library to make us
💯
> On Jun 7, 2017, at 10:35 AM, Adam Sharp via swift-evolution
> wrote:
>
> The new smart key path feature is really lovely, and feels like a great
> addition to Swift.
>
> It seems like it might be straightforward to add overloads of `map` and
> `flatMap` to the standard library to make us
> On Mar 17, 2017, at 6:38 PM, Joe Groff via swift-evolution
> wrote:
>
>
>> On Mar 17, 2017, at 12:34 PM, David Hart via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> Sent off-list by mistake:
>>
>> Nice proposal. I have a few comments inline:
>>
>>> On 17 Mar 2017, a
I have two related questions:
1. Why was Swift 4 chosen as the target release for adding archival and
serialization?
2. Given Swift compatibility requirements going forward, how much will the
design of these APIs be able to change?
The overall impression I get from the APIs is that they’ve
