> On 16 Mar 2017, at 21:48, Slava Pestov via swift-evolution
> <[email protected]> wrote:
>
> Hi Itai,
>
> I’m wondering what the motivation is for keeping this as part of Foundation
> and not the standard library. It seems like you’re landing an implementation
> of this in the Foundation overlay on master, and another copy of all the code
> will have to go into swift-corelibs-foundation. This seems suboptimal. Or are
> there future plans to unify the Foundation overlay with corelibs-foundation
> somehow?
>
> Also the implementation uses some Foundation-isms (NSMutableArray, NSNumber)
> and it would be nice to stick with idiomatic Swift as much as possible
> instead.
>
> Finally you should take a look at the integer protocol work
> (https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md
>
> <https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>)
> to replace the repetitive code surrounding primitive types, however I don’t
> know if this has landed in master yet.
>
> Slava
I agree that the protocols should be part of the standard library rather than
Foundation. As far as I can make out, the only part of this proposal that
actually requires Foundation is the use of the “Data” type (which itself is a
strange and often frustrating omission from the standard library). The actual
concrete encoders can live in Foundation.
Generally my opinion is that the proposed feature is nice. Everybody hates
NSCoder and having to write those required initialisers on your UIViews and
whatnot. At its core, it’s not really very different from any other Swift
archiving library which exists today, except that it’s backed with layer upon
layer of compiler-generated magic to make it less verbose. The things I don’t
like:
1) While making things less verbose is commendable, automatically generating
the encoding functions could be an anti-feature. “Codable” is for properties
with persistable values only, which is a level of semantics which goes above
the type-system. We don’t generate Equatable conformance for structs whose
elements are all Equatable; it’s a big leap to go from “this data type is
persistable” to “the value of this variable should be persisted” - for one
thing, the value may not have meaning to others (e.g. a file-handle as an
Int32) or it may contain sensitive user-data in a String. The encoding function
isn’t just boilerplate - you *should* think about it; otherwise who knows what
kind of data you’re leaking?
=> One possible solution would be to have “Codable" as a regular protocol, and
refine it with “AutoCodable" which contains the magic. Just so there is a
little extra step where you think “do I want this to be generated?”.
2) More generally, though, I don’t support the idea of the Foundation module
introducing extensions to the Swift language that no other developer of any
other module has the chance to do, with an aside that some reflection API which
doesn’t exist yet might possibly make it less magic in the future. My jaw hit
the floor when I saw this was part of the proposal, and that it wasn’t for the
standard library. Could you imagine, if somebody proposed their own magic
protocols for AlamoFire or Kitura or any other Swift library? It would be a
non-starter. It *should* be a non-starter.
=> Do we have a policy about module-specific compiler magic such as this?
=> Can we move any of the magic (e.g. CodableKeys generation) to the standard
library?
I develop a lot for platforms, or for scenarios, where Foundation is not
supported nor desirable. Considering that people are taught to prefer library
code to rolling their own, and that humans are generally quite receptive to
shortcuts at the expense of correctness, if this machinery exists at all we can
expect it to spread. It would totally kill libraries such as SwiftJSON or
whatever else you currently use. The fact that such a fundamental and
widespread feature would now live in a monolithic module I can’t access would
significantly spoil the language for me.
- Karl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
