Hi Karl,
> On Apr 22, 2017, at 6:23 AM, Karl Wagner <[email protected]> wrote:
>
>>
>> On 20 Apr 2017, at 19:08, Tony Parker via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Hi everyone,
>>
>> Thanks for your feedback on this proposal. Based on that plus additional
>> feedback from core team members and others who responded off-thread, we are
>> making the following small adjustments:
>>
>> * KeyedEncoderContainerProtocol, KeyedDecodingContainerProtocol,
>> UnkeyedEncodingContainer, UnkeyedDecodingContainer,
>> SingleValueEncodingContainer, SingleValueDecodingContainer will drop their
>> Data-taking functions. Data will conform to Codable, so it just goes through
>> the normal paths like other types.
>> * The above will allow those protocols, plus Encodable, Decodable, typealias
>> Codable, Encoder, Decoder, CodingKey, struct CodingUserInfoKey to be part
>> of the standard library (not in Foundation), resolving the concern about
>> reaching too far up the stack for the compiler.
>> * JSONEncoder/Decoder, PropertyListEncoder/Decoder remain in Foundation.
>> These are concrete implementations of the above protocols, like the ones
>> that will appear in many libraries, we hope.
>>
>> We are not currently proposing using the integer protocols. The reasoning is
>> that using them them confers a requirement upon all possible encoders and
>> decoders to support arbitrary-width integers and floating point values.
>> We’re not convinced this is feasible, but we will continue to evaluate.
>>
>> If the core team accepts the modified proposal, we will get this merged as
>> soon as possible with the goal of allowing all of you to try everything out
>> via Swift’s frequent toolchain snapshots. We will be looking for feedback on
>> how it works in more real world scenarios, and we will consider further
>> adjustments to the API before Swift 4 is final. We are hoping that this
>> extended trial period will allow us to make sure that everything works out
>> the way we expected.
>>
>> Thanks,
>> - Tony
>
>
> That’s a great step; thanks a lot!
>
> As for Data/UnsafeRawBufferPointer (beyond this proposal): I agree that a
> Data object which owns its buffer should be the common-currency for passing
> buffers around, but I also think that the standard library should own that
> “Data” type. Data is (IMO), no less "primitive” than, say, Array, Dictionary,
> Set and String - yet while all of those types are part of the standard
> library, Data lives much further down the stack, in Foundation. The standard
> library is limited to unsafe buffers, without a “safe” alternative. Even
> though Foundation is a core library and very useful, it is still an optional
> component of any Swift installation or application, and I feel it’s not
> unreasonable to ask for a safe buffer without that dependency.
>
> I could of course define my own RAII, UnsafeRawBufferPointer-wrapping “Data”
> type, but then it either spreads throughout my API and undermines Data as a
> common currency, or I need to convert it (with a copy, in order to preserve
> value semantics). This is the same issue that affects DispatchData/Data
> bridging, which in that case undermines APIs such as DispatchIO; either all
> of my APIs now take a DispatchData (leaking implementation details), or I
> have to copy the buffer in to a Foundation Data.
>
We’re aware of this, but it’s something I’d like to tackle separately from the
Coding proposals.
> That’s an issue which I would like to help solve more comprehensively one
> day, but for the mean time:
>
> 1) Is untyped data really a “primitive” in the context of serialisation? If
> so...
> 2) Why are we removing it? Is it only because the standard library lacks a
> good type to represent the data? If so...
> 3) Why not introduce a generic function?
>
> mutating func encodeBytes<C>(_ bytes: C, forKey key: Key) throws where C:
> Collection, C.Element == UInt8
>
> This single function would be able to encode Data, DispatchData,
> UnsafeRawBufferPointer, and even an Array<UInt8>.
>
> - Karl
We considered something along these lines:
func encode<T : Encodable>(_ value: T?, ...) // existing
func encode<T : RangeRepleaceableCollection>(_ value: T?, ...) where
T.Iterator.Element == UInt8
but this is ambiguous when we have conditional conformance and Array where
Element : Encodable is Encodable. Did you mean to encode base64-encoded data
for JSON or an array of UInt8? Data resolves the ambiguity by assigning more
meaning to a Collection of UInt8.
We could resolve the ambiguity by using a different name (like you suggest
above), but this reduces the viability of Data as a common currency type, which
we believe is very important. Ultimately we felt that going with one less
primitive here was a better approach.
- Tony
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
