Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Jon Shier via swift-evolution]

> What is your evaluation of the proposal?
-1. There is a lot good here, but this feature is too important to let an 
“okay” proposal through.

* Usage of the API doesn’t feel very Swifty, unless I’m missing some intended 
use case. Why are the encoders / decoders classes? Why do they have mutable 
properties? What is the userInfo value for? It all feels very reminiscent of 
the NSFormatter APIs, which isn’t really a good thing. This is supposed to be 
the Swift native way to encode and decode types, so it should feel native. It’s 
close in a lot of ways (I like the strategies enums) but isn’t really there. 

* This is more for 166, but decode(MyValue.self)? Gross. Use the generic to 
convey the type inside the API.

* This proposal fails to make full usage of the Swift’s error capabilities and 
the errors live in the wrong place. I’m putting this here since this proposal 
defines the errors but really they should be part of 166. These error types are 
inferior to the errors we can produce in Swift right now. They should be Swift 
native errors first and bridged into NSError second, not created with the 
primary intent to be bridged. For example:

public static var coderTypeMismatch: CocoaError.Code

First off, the coder* prefix is unnecessary if this is properly moved into its 
own concrete error type. Second, it doesn’t capture the mismatch values, 
leading to unnecessary debugging overhead. Make the error a proper enum that 
can capture the type found and type expected and it becomes far more useful. 
For example (roughly):

public enum DecoderError: Error {
typeMismatch(expected:actual:)
readCorrupt(underlyingError: Error) // presumably this wraps the underlying 
serialization error?
valueNotFound(forKey: Key)
}

Also, these errors should live in the standard library, otherwise how are 
native types going do their own encoding/decoding without importing Foundation. 
Again, this is more for 166, but they were defined here, so… I understand the 
need to perhaps bridge them to existing errors (I don’t think it’s necessary, 
but I understand the desire), but that should be done under the covers, so to 
speak, and not exposed to Swift developers by limiting a core API so badly. 
Besides, the errors you want to bridge to aren’t very good in the first place. 
"The data couldn't be read because it isn't in the correct format.” Seriously? 
Could we get a little more detail, please?

* There is nothing proposed to add any type safety to the decoding process. We 
know exactly what types can exist in JSON. Why are we still representing it as 
Any or the raw Data? Providing greater safety during the decoding process helps 
developers find what’s wrong faster.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, we need native decoding and encoding of common formats like JSON, but I 
don’t believe this solution is good enough.

> Does this proposal fit well with the feel and direction of Swift?
No, this feels like a port of an Objective-C API, and it literally is in some 
ways.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I’ve been using Argo for 2 years now. While much of the comparison is more 
relevant to 166, I think it’s still a great example of what a Swift native 
decoding experience should look like. It’s especially superior in the errors it 
produces.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Fairly in depth I’d say.



Jon Shier

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Douglas Gregor via swift-evolution]

> On Apr 12, 2017, at 11:49 AM, Russ Bishop  wrote:
> 
> Doug,
> 
> Would it be worth deferring this slightly since it relies on SE-0166? If 
> changes are made to SE-0166 as a result of review it will necessarily impact 
> this proposal.

If there are changes to SE-0166 that affect this, we can always hold off on a 
decision to make more adjustments. I don’t think we need to stagger the review 
of two closely-related proposals like this.

- Doug

> 
> 
> Russ Bishop
> 
> 
>> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
>> 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>>  
>> 
>> Note that this proposal is closely related to (and dependent on) SE-0166: 
>> Swift Archival & Serialization 
>> .
>>  Please read and review that proposal as well!
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>>  
>> 
>> Reply text
>> Other replies
>>  
>> What
>>  goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Does this proposal fit well with the feel and direction of Swift?
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md 
>> 
>> Thank you,
>> 
>> -Doug
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0167: Swift Encoders

[Brad Hilton via swift-evolution]

-1. I left my feedback for this proposal and SE-0166 on the other thread, but 
TLDR; I think this is premature until we add true reflection capabilities
to Swift.

> Hello Swift community,
> 
> 
> The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
> 2017. The proposal is available here:
> 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
> Note that this proposal is closely related to (and dependent on)SE-0166: 
> Swift 
> Archival(https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md).
>  Please read and review that proposal as well!
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> > 
> > Proposal link:
> > 
> > > https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
> > 
> > Reply text
> > > Other replies
> > 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> 
> More information about the Swift evolution process is available at
> 
> > https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> 
> -Doug
> 
> 
> Review Manager
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Russ Bishop via swift-evolution]

Doug,

Would it be worth deferring this slightly since it relies on SE-0166? If 
changes are made to SE-0166 as a result of review it will necessarily impact 
this proposal.


Russ Bishop


> On Apr 6, 2017, at 11:10 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
> 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>  
> 
> Note that this proposal is closely related to (and dependent on) SE-0166: 
> Swift Archival & Serialization 
> .
>  Please read and review that proposal as well!
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>  
> 
> Reply text
> Other replies
>  
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Apr 12, 2017, at 2:53 AM, piotr gorzelany via swift-evolution 
>  wrote:
> 
> For me it boils down to a question if Data is the best type to represent 
> JSON. Data is really generic, you could serialize an UIImage into data and 
> pass it to the decoding function.

Data is what you read from and write to disk and network and therefore the 
appropriate choice for these APIs.

> 
> Yes, JSON is not a very strong type but that is the nature of JSON, it is a 
> dynamic data structure like a dictionary. But giving it a type gives us 
> future flexibility to extend it if needed. 
> 
> Also, raw JSON manipulation is common practice since the server does not 
> always give you the perfect JSON to deserialize into a model object.
> 
> Say you have a model object with some nested objects in it. To initialize 
> them from JSON you will need to full JSON for all the objects. But the common 
> practice is that the server will return only the full top level object and 
> IDs for the nest d objects so you fetch them separately.  
> 
> W dniu pon., 10.04.2017 o 22:47 Jordan Rose  
> napisał(a):
>> 
 On Apr 10, 2017, at 02:52, David Hart via swift-evolution 
  wrote:
 
 
 On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution 
  wrote:
 
 This is a really great proposal. As an iOS developer I work with JSON 
 almost every day since most mobile apps communicate with a backend through 
 JSON messages. It's good to see that better JSON support is coming to 
 Foundation so we don't have to rely on third party libraries.
 
 That being said, there is one thing I don't like which is that the JSON 
 encoding function returns Data and the decoding function takes Data.
 
 It would be really great if the Foundation team could introduce a 
 dedicated type of JSON.
 There are several advantages of working with a dedicated type.
 - The underlying data is always valid JSON
 - You can extend this type in the future with helper methods for 
 manipulating JSON
 - It makes it explicit what you are dealing with
 
 A good analogy is the URL type. You could represent an URL with a String 
 or Data type, but by introducing a dedicated type you have the full 
 advantages mentioned above. Data on the other hand is like a generic 
 container which you cannot easily extend with URL or JSON specific methods.
 
 Having a dedicated JSON type is also one of the reasons third party 
 libraries like SwiftyJSON are so popular. It makes it super easy to 
 manipulate JSON structures. And sometimes developers like would like to 
 manipulate JSON directly.
>>> 
>>> I don’t think it would be a good thing to have this in Foundation. 
>>> Foundation needs to push developers towards adopting best practices, and 
>>> manipulating JSON directly instead of going through Codable’s strong-typing 
>>> is not necessarily recommended. I’m not saying it doesn’t have its uses. 
>>> But it’s usefulness is definitely narrow now once we have Codable. I think 
>>> this is something that should stay in a third-party library.
>> 
>> I haven't thought heavily about this, but the thoughts that I have say that 
>> JSON just isn't a good type in Swift. It's not an efficient in-memory 
>> representation and it's not a convenient structural representation (because 
>> of the use of either 'Any' or 'JSON' in the recursive position). I'll admit 
>> that sometimes you're handed some JSON and you want to extract a little bit 
>> of information out of it without building a typed representation of the 
>> whole thing, but that still seems like something that doesn't need to be the 
>> common path.
>> 
>> Jordan
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[piotr gorzelany via swift-evolution]

For me it boils down to a question if Data is the best type to represent
JSON. Data is really generic, you could serialize an UIImage into data and
pass it to the decoding function.

Yes, JSON is not a very strong type but that is the nature of JSON, it is a
dynamic data structure like a dictionary. But giving it a type gives us
future flexibility to extend it if needed.

Also, raw JSON manipulation is common practice since the server does not
always give you the perfect JSON to deserialize into a model object.

Say you have a model object with some nested objects in it. To initialize
them from JSON you will need to full JSON for all the objects. But the
common practice is that the server will return only the full top level
object and IDs for the nest d objects so you fetch them separately.

W dniu pon., 10.04.2017 o 22:47 Jordan Rose 
napisał(a):

>
> On Apr 10, 2017, at 02:52, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is a really great proposal. As an iOS developer I work with JSON
> almost every day since most mobile apps communicate with a backend through
> JSON messages. It's good to see that better JSON support is coming to
> Foundation so we don't have to rely on third party libraries.
>
> That being said, there is one thing I don't like which is that the JSON
> encoding function returns Data and the decoding function takes Data.
>
> It would be really great if the Foundation team could introduce a
> dedicated type of JSON.
> There are several advantages of working with a dedicated type.
> - The underlying data is always valid JSON
> - You can extend this type in the future with helper methods for
> manipulating JSON
> - It makes it explicit what you are dealing with
>
> A good analogy is the URL type. You could represent an URL with a String
> or Data type, but by introducing a dedicated type you have the full
> advantages mentioned above. Data on the other hand is like a generic
> container which you cannot easily extend with URL or JSON specific methods.
>
> Having a dedicated JSON type is also one of the reasons third party
> libraries like SwiftyJSON are so popular. It makes it super easy to
> manipulate JSON structures. And sometimes developers like would like to
> manipulate JSON directly.
>
>
> I don’t think it would be a good thing to have this in Foundation.
> Foundation needs to push developers towards adopting best practices, and
> manipulating JSON directly instead of going through Codable’s strong-typing
> is not necessarily recommended. I’m not saying it doesn’t have its uses.
> But it’s usefulness is definitely narrow now once we have Codable. I think
> this is something that should stay in a third-party library.
>
>
> I haven't thought *heavily* about this, but the thoughts that I have say
> that JSON just isn't a good type in Swift. It's not an efficient in-memory
> representation and it's not a convenient structural representation (because
> of the use of either 'Any' or 'JSON' in the recursive position). I'll admit
> that sometimes you're handed some JSON and you want to extract a little bit
> of information out of it without building a typed representation of the
> whole thing, but that still seems like something that doesn't need to be
> the common path.
>
> Jordan
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
 
]

There's some pretty cool stuff in here. Nice work. I do have a few questions 
about this design, though:

- Why are the encoders and decoders open classes? (In particular, the fixed set 
of "strategies" seems like it'll be a problem if we plan to keep adding cases.) 
For that matter, why make them classes at all?

- I don't understand 'DateEncodingStrategy.deferredToDate'. It seems like this 
will always match one of the other cases in practice, and it isn't safe for any 
stable encoding.

- I assume you've thought about this, but there's no way for existing Cocoa 
types to conform to Decodable, since it introduces a new required initializer.* 
The design here doesn't rely on that at all, but I feel like it's worth calling 
out explicitly.


* Why does Decodable introduce a required initializer? Because when a class 
conforms to a protocol, it's declaring that it and all its subclasses conform 
to the protocol. But since initializers are not automatically inherited in 
Swift, there's no way to add new initializers to all existing subclasses.

Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 3:47 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Apr 10, 2017, at 02:52, David Hart via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution 
>>> > wrote:
>>> 
>>> This is a really great proposal. As an iOS developer I work with JSON 
>>> almost every day since most mobile apps communicate with a backend through 
>>> JSON messages. It's good to see that better JSON support is coming to 
>>> Foundation so we don't have to rely on third party libraries.
>>> 
>>> That being said, there is one thing I don't like which is that the JSON 
>>> encoding function returns Data and the decoding function takes Data.
>>> 
>>> It would be really great if the Foundation team could introduce a dedicated 
>>> type of JSON.
>>> There are several advantages of working with a dedicated type.
>>> - The underlying data is always valid JSON
>>> - You can extend this type in the future with helper methods for 
>>> manipulating JSON
>>> - It makes it explicit what you are dealing with
>>> 
>>> A good analogy is the URL type. You could represent an URL with a String or 
>>> Data type, but by introducing a dedicated type you have the full advantages 
>>> mentioned above. Data on the other hand is like a generic container which 
>>> you cannot easily extend with URL or JSON specific methods.
>>> 
>>> Having a dedicated JSON type is also one of the reasons third party 
>>> libraries like SwiftyJSON are so popular. It makes it super easy to 
>>> manipulate JSON structures. And sometimes developers like would like to 
>>> manipulate JSON directly.
>> 
>> I don’t think it would be a good thing to have this in Foundation. 
>> Foundation needs to push developers towards adopting best practices, and 
>> manipulating JSON directly instead of going through Codable’s strong-typing 
>> is not necessarily recommended. I’m not saying it doesn’t have its uses. But 
>> it’s usefulness is definitely narrow now once we have Codable. I think this 
>> is something that should stay in a third-party library.
> 
> I haven't thought heavily about this, but the thoughts that I have say that 
> JSON just isn't a good type in Swift. It's not an efficient in-memory 
> representation and it's not a convenient structural representation (because 
> of the use of either 'Any' or 'JSON' in the recursive position). I'll admit 
> that sometimes you're handed some JSON and you want to extract a little bit 
> of information out of it without building a typed representation of the whole 
> thing, but that still seems like something that doesn't need to be the common 
> path.

I agree.  It seems orthogonal to this proposal to me.  It would be easy enough 
for a library to add a Codable JSON type on top of this proposal.  Foundation 
could even do that in the future if there was strong enough motivation for it.

> 
> Jordan
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[Jordan Rose via swift-evolution]

> On Apr 10, 2017, at 02:52, David Hart via swift-evolution 
>  wrote:
> 
>> 
>> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution 
>> > wrote:
>> 
>> This is a really great proposal. As an iOS developer I work with JSON almost 
>> every day since most mobile apps communicate with a backend through JSON 
>> messages. It's good to see that better JSON support is coming to Foundation 
>> so we don't have to rely on third party libraries.
>> 
>> That being said, there is one thing I don't like which is that the JSON 
>> encoding function returns Data and the decoding function takes Data.
>> 
>> It would be really great if the Foundation team could introduce a dedicated 
>> type of JSON.
>> There are several advantages of working with a dedicated type.
>> - The underlying data is always valid JSON
>> - You can extend this type in the future with helper methods for 
>> manipulating JSON
>> - It makes it explicit what you are dealing with
>> 
>> A good analogy is the URL type. You could represent an URL with a String or 
>> Data type, but by introducing a dedicated type you have the full advantages 
>> mentioned above. Data on the other hand is like a generic container which 
>> you cannot easily extend with URL or JSON specific methods.
>> 
>> Having a dedicated JSON type is also one of the reasons third party 
>> libraries like SwiftyJSON are so popular. It makes it super easy to 
>> manipulate JSON structures. And sometimes developers like would like to 
>> manipulate JSON directly.
> 
> I don’t think it would be a good thing to have this in Foundation. Foundation 
> needs to push developers towards adopting best practices, and manipulating 
> JSON directly instead of going through Codable’s strong-typing is not 
> necessarily recommended. I’m not saying it doesn’t have its uses. But it’s 
> usefulness is definitely narrow now once we have Codable. I think this is 
> something that should stay in a third-party library.

I haven't thought heavily about this, but the thoughts that I have say that 
JSON just isn't a good type in Swift. It's not an efficient in-memory 
representation and it's not a convenient structural representation (because of 
the use of either 'Any' or 'JSON' in the recursive position). I'll admit that 
sometimes you're handed some JSON and you want to extract a little bit of 
information out of it without building a typed representation of the whole 
thing, but that still seems like something that doesn't need to be the common 
path.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

[David Hart via swift-evolution]

> On 10 Apr 2017, at 11:36, piotr gorzelany via swift-evolution 
>  wrote:
> 
> This is a really great proposal. As an iOS developer I work with JSON almost 
> every day since most mobile apps communicate with a backend through JSON 
> messages. It's good to see that better JSON support is coming to Foundation 
> so we don't have to rely on third party libraries.
> 
> That being said, there is one thing I don't like which is that the JSON 
> encoding function returns Data and the decoding function takes Data.
> 
> It would be really great if the Foundation team could introduce a dedicated 
> type of JSON.
> There are several advantages of working with a dedicated type.
> - The underlying data is always valid JSON
> - You can extend this type in the future with helper methods for manipulating 
> JSON
> - It makes it explicit what you are dealing with
> 
> A good analogy is the URL type. You could represent an URL with a String or 
> Data type, but by introducing a dedicated type you have the full advantages 
> mentioned above. Data on the other hand is like a generic container which you 
> cannot easily extend with URL or JSON specific methods.
> 
> Having a dedicated JSON type is also one of the reasons third party libraries 
> like SwiftyJSON are so popular. It makes it super easy to manipulate JSON 
> structures. And sometimes developers like would like to manipulate JSON 
> directly.

I don’t think it would be a good thing to have this in Foundation. Foundation 
needs to push developers towards adopting best practices, and manipulating JSON 
directly instead of going through Codable’s strong-typing is not necessarily 
recommended. I’m not saying it doesn’t have its uses. But it’s usefulness is 
definitely narrow now once we have Codable. I think this is something that 
should stay in a third-party library.

> If the proposal would pass in the current form, I would still use SwiftyJSON 
> for manipulating JSON which I would rather avoid and have this all sorted on 
> the Foundation level.
> 
> Just my two cents from the perspective of an iOS developer. JSON handling is 
> really important to us so I hope you make it great!
> 
> 
> Hello Swift community,
> 
> The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
> 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>  
> 
> Note that this proposal is closely related to (and dependent on) SE-0166: 
> Swift Archival & Serialization 
>   
> >.
>  Please read and review that proposal as well!
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
>  
>  >
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
>  
> 
> Reply text
> Other replies
>  
>   
> >What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
>  
>  >
> 

[swift-evolution] [Review] SE-0167: Swift Encoders

[piotr gorzelany via swift-evolution]

This is a really great proposal. As an iOS developer I work with JSON
almost every day since most mobile apps communicate with a backend through
JSON messages. It's good to see that better JSON support is coming to
Foundation so we don't have to rely on third party libraries.

That being said, there is one thing I don't like which is that the JSON
encoding function returns Data and the decoding function takes Data.

It would be really great if the Foundation team could introduce a dedicated
type of JSON.
There are several advantages of working with a dedicated type.
- The underlying data is always valid JSON
- You can extend this type in the future with helper methods for
manipulating JSON
- It makes it explicit what you are dealing with

A good analogy is the URL type. You could represent an URL with a String or
Data type, but by introducing a dedicated type you have the full advantages
mentioned above. Data on the other hand is like a generic container which
you cannot easily extend with URL or JSON specific methods.

Having a dedicated JSON type is also one of the reasons third party
libraries like SwiftyJSON are so popular. It makes it super easy to
manipulate JSON structures. And sometimes developers like would like to
manipulate JSON directly.

If the proposal would pass in the current form, I would still use
SwiftyJSON for manipulating JSON which I would rather avoid and have this
all sorted on the Foundation level.

Just my two cents from the perspective of an iOS developer. JSON handling
is really important to us so I hope you make it great!



Hello Swift community,

The review of SE-0167 "Swift Encoders" begins now and runs through
April 12, 2017. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
Note that this proposal is closely related to (and dependent on)
SE-0166: Swift Archival & Serialization
.
Please read and review that proposal as well!

Reviews are an important part of the Swift evolution process. All
reviews should be sent to the swift-evolution mailing list at
https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at
the top of the message:

Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
Reply text
Other replies
 
What
goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the
direction of Swift. When writing your review, here are some questions
you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
More information about the Swift evolution process is available at
https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Review] SE-0167: Swift Encoders

[Douglas Gregor via swift-evolution]

Hello Swift community,

The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 
2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
Note that this proposal is closely related to (and dependent on) SE-0166: Swift 
Archival & Serialization 
.
 Please read and review that proposal as well!

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution 

or, if you would like to keep your feedback private, directly to the review 
manager. When replying, please try to keep the proposal link at the top of the 
message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md
Reply text
Other replies
 
What
 goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md 

Thank you,

-Doug

Review Manager
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution