Re: [swift-users] Parsing Decimal values from JSON

[Ireland, Evan via swift-users]

Rimantas,

At json.org the grammar for numbers does not limit the precision to IEEE double 
precision.

There are specifications (e.g. OData 4.0) which pemit decimal/integer values 
being encoded as JSON numbers that might go outside the range of IEEE double, 
with an expectation that agents (clients and servers) will preserve the 
precision.

Such encodings can present interoperability issues with parsers (such as a 
typical JavaScript/JSON parser), and clearly also this is affecting Swift.

Therefore you may find that when working with such specifications, and with 
JSON parsing in Swift, you need your own (or a third-party) JSON parser if 
arbitrary integer/decimal precision needs to be retained when using JSON 
numbers rather than JSON strings for the arbitrary precision integer/decimal 
encoding.

Some folks might wish to consider this as a defect in the JSON parser, others 
may see it as an issue with the way that values are being encoded in JSON. 

Now I-JSON (see 
https://datatracker.ietf.org/doc/draft-ietf-json-i-json/03/?include_text=1) 
defines some extra constraints to avoid such interoperability issues.

> From: Rimantas Liubertas 
> To: swift-users 
> Subject: Re: [swift-users] Parsing Decimal values from JSON
> 
> > Swift shouldn't be forced to adhere to the limitations of JavaScript. Just
> > because JS doesn't know about decimals doesn't mean swift can't do better.
> >
> JSON does not know about decimals either. http://json.org/. If you need
> some custom data type you can always pass it as a string and then handle as
> needed.
> 
> Best regards,
> Rimantas
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Justification for Swift Design Decisions?

[Michael Rogers via swift-users]

> On Oct 31, 2017, at 3:39 PM, Austin Zheng  wrote:
> 
> To expand on this, most (if not all) the proposals in the list of proposals 
> on GitHub (https://github.com/apple/swift-evolution/tree/master/proposals 
> ) have a 
> "Rationale" link to a mailing list archive post by one of the Swift core team 
> members explaining why a certain decision was reached. Those are probably 
> worth looking through. Some of the simpler and less controversial proposals 
> have almost no explanation, but the larger and controversial proposals have 
> extensively written-up rationale posts.

This is perfect, thank you! And it is comforting to see that so much thought 
went into these decisions ...

Michael___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Justification for Swift Design Decisions?

[Austin Zheng via swift-users]

To expand on this, most (if not all) the proposals in the list of proposals
on GitHub (https://github.com/apple/swift-evolution/tree/master/proposals)
have a "Rationale" link to a mailing list archive post by one of the Swift
core team members explaining why a certain decision was reached. Those are
probably worth looking through. Some of the simpler and less controversial
proposals have almost no explanation, but the larger and controversial
proposals have extensively written-up rationale posts.

Best,
Austin

On Tue, Oct 31, 2017 at 12:25 PM, David Sweeris via swift-users <
swift-users@swift.org> wrote:

> Specifically WRT to double quotes for characters, the Commonly Rejected
> Changes doc (https://github.com/apple/swift-evolution/blob/master/
> commonly_proposed.md) says, "Swift takes the approach of highly valuing
> Unicode. However, there are multiple concepts of a character that could
> make sense in Unicode, and none is so much more commonly used than the
> others that it makes sense to privilege them. We'd rather save single
> quoted literals for a greater purpose (e.g. non-escaped string literals)."
>
> Otherwise, off the top of my head I'm not sure. If it's a particularly
> controversial decision, there's a fair chance it's come up on the
> swift-evolution list, though, so maybe search its archives?
>
> Hope that helps,
> - Dave Sweeris
>
> > On Oct 31, 2017, at 8:52 AM, Michael Rogers via swift-users <
> swift-users@swift.org> wrote:
> >
> > Hi, All:
> >
> > I’m giving a presentation on Swift this weekend, and am trying to find
> justification for some of the design decisions that they made. Is there
> anything out there that goes into the detail of this? Like … why did the
> use “ for characters, or \() for String interpolation?
> >
> > Thanks,
> >
> > Michael
> > ___
> > swift-users mailing list
> > swift-users@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-users
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Justification for Swift Design Decisions?

[David Sweeris via swift-users]

Specifically WRT to double quotes for characters, the Commonly Rejected Changes 
doc (https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md) 
says, "Swift takes the approach of highly valuing Unicode. However, there are 
multiple concepts of a character that could make sense in Unicode, and none is 
so much more commonly used than the others that it makes sense to privilege 
them. We'd rather save single quoted literals for a greater purpose (e.g. 
non-escaped string literals)."

Otherwise, off the top of my head I'm not sure. If it's a particularly 
controversial decision, there's a fair chance it's come up on the 
swift-evolution list, though, so maybe search its archives?

Hope that helps,
- Dave Sweeris

> On Oct 31, 2017, at 8:52 AM, Michael Rogers via swift-users 
>  wrote:
> 
> Hi, All:
> 
> I’m giving a presentation on Swift this weekend, and am trying to find 
> justification for some of the design decisions that they made. Is there 
> anything out there that goes into the detail of this? Like … why did the use 
> “ for characters, or \() for String interpolation?
> 
> Thanks,
> 
> Michael
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Parsing Decimal values from JSON

[Itai Ferber via swift-users]

I can’t speak to any resistance you’ve seen from the Swift team (nor 
to any performance issues you’ve encountered with 
`JSONSerialization`), but just keep in mind that

a) `JSONSerialization` is maintained by the Foundation team, and
b) maintaining a separate JSON parsing implementation just for Swift is 
a great way to introduce new, separate, likely incompatible bugs


That being said, we’ve considered it, and continue to consider it — 
there is just a cost-benefit analysis that goes into prioritizing 
developer time.


On 31 Oct 2017, at 10:18, Jon Shier wrote:

The appropriate solution here would be for Swift to have its own 
native JSON parser that allows direct decoding into generic types 
without the intermediary of JSONSerialization. For whatever reason 
there seems to be resistance to this from the Swift team, but until we 
have that ability, these types of issues will keep coming up, and the 
performance overhead of JSONSerialization with JSONDecoder on top of 
it will continue to leave Swift without a very performant JSON 
solution.

That said, I appreciate the support given Codable on this list.



Jon

On Oct 31, 2017, at 1:07 PM, Itai Ferber via swift-users 
 wrote:


Hi Evtim,

Just want to give some context for this.
This is due to the fact that JSONEncoder and JSONDecoder are 
currently based on JSONSerialization: when you go to decode some JSON 
data, the data is deserialized using JSONSerialization, and then 
decoded into your types by JSONDecoder. At the JSONSerialization 
level, however, there is no way to know whether a given numeric value 
is meant to be interpreted as a Double or as a Decimal.


There are subtle differences to decoding as either, so there is no 
behavior that could satisfy all use cases. JSONSerialization has to 
make a decision, so if the number could fit losslessly in a Double, 
it will prefer that to a Decimal. This allows guaranteed precise 
round-tripping of all Double values at the cost of different behavior 
when decoding a Decimal.


In practice, this might not really matter in the end based on how you 
use the number (e.g. the loss in precision can be so minute as to be 
insignificant) — what is your use case here? And can you give some 
numeric values for which this is problematic for you?


As others have mentioned, one way to guarantee decoding a numeric 
string in a specific way is to actually encode it and decode it as a 
String, then convert into a Decimal where you need it, e.g.


import Foundation

struct Foo : Codable {
var number: Decimal

public init(number: Decimal) {
self.number = number
}

private enum CodingKeys : String, CodingKey {
case number
}

public init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: 
CodingKeys.self)
let stringValue = try container.decode(String.self, forKey: 
.number)

guard let decimal = Decimal(string: stringValue) else {
throw DecodingError.dataCorruptedError(forKey: .number, 
in: container, debugDescription: "Invalid numeric value.")

}

self.number = decimal
}

public func encode(to encoder: Encoder) throws {
var container = encoder.container(keyedBy: CodingKeys.self)
try container.encode(self.number.description, forKey: 
.number)

}
}


let foo = Foo(number: Decimal(string: 
"2.71828182845904523536028747135266249775")!)
print(foo) // => Foo(number: 
2.71828182845904523536028747135266249775)


let encoder = JSONEncoder()
let data = try encoder.encode(foo)
print(String(data: data, encoding: .utf8)!) // => 
{"number":"2.71828182845904523536028747135266249775"}


let decoder = JSONDecoder()
let decoded = try decoder.decode(Foo.self, from: data)
print(decoded) // => Foo(number: 
2.71828182845904523536028747135266249775)


print(decoded.number == foo.number) // => true
— Itai

On 28 Oct 2017, at 11:23, Evtim Papushev via swift-users wrote:

Hello :)

I am trying to find a way to parse a number as Decimal without losing 
the number's precision.


It seems that the JSON decoder parses it as Double then converts it 
to Decimal which introduces errors in the parsing. That behavior is 
in fact incorrect.


Does anyone know if there is a way to obtain the raw data for this 
specific field so I can write the conversion code?


Thanks,
Evtim

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


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



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

Re: [swift-users] Parsing Decimal values from JSON

[Jon Shier via swift-users]

The appropriate solution here would be for Swift to have its own native 
JSON parser that allows direct decoding into generic types without the 
intermediary of JSONSerialization. For whatever reason there seems to be 
resistance to this from the Swift team, but until we have that ability, these 
types of issues will keep coming up, and the performance overhead of 
JSONSerialization with JSONDecoder on top of it will continue to leave Swift 
without a very performant JSON solution. 
That said, I appreciate the support given Codable on this list.



Jon

> On Oct 31, 2017, at 1:07 PM, Itai Ferber via swift-users 
>  wrote:
> 
> Hi Evtim,
> 
> Just want to give some context for this.
> This is due to the fact that JSONEncoder and JSONDecoder are currently based 
> on JSONSerialization: when you go to decode some JSON data, the data is 
> deserialized using JSONSerialization, and then decoded into your types by 
> JSONDecoder. At the JSONSerialization level, however, there is no way to know 
> whether a given numeric value is meant to be interpreted as a Double or as a 
> Decimal.
> 
> There are subtle differences to decoding as either, so there is no behavior 
> that could satisfy all use cases. JSONSerialization has to make a decision, 
> so if the number could fit losslessly in a Double, it will prefer that to a 
> Decimal. This allows guaranteed precise round-tripping of all Double values 
> at the cost of different behavior when decoding a Decimal.
> 
> In practice, this might not really matter in the end based on how you use the 
> number (e.g. the loss in precision can be so minute as to be insignificant) — 
> what is your use case here? And can you give some numeric values for which 
> this is problematic for you?
> 
> As others have mentioned, one way to guarantee decoding a numeric string in a 
> specific way is to actually encode it and decode it as a String, then convert 
> into a Decimal where you need it, e.g.
> 
> import Foundation
> 
> struct Foo : Codable {
> var number: Decimal
> 
> public init(number: Decimal) {
> self.number = number
> }
> 
> private enum CodingKeys : String, CodingKey {
> case number
> }
> 
> public init(from decoder: Decoder) throws {
> let container = try decoder.container(keyedBy: CodingKeys.self)
> let stringValue = try container.decode(String.self, forKey: .number)
> guard let decimal = Decimal(string: stringValue) else {
> throw DecodingError.dataCorruptedError(forKey: .number, in: 
> container, debugDescription: "Invalid numeric value.")
> }
> 
> self.number = decimal
> }
> 
> public func encode(to encoder: Encoder) throws {
> var container = encoder.container(keyedBy: CodingKeys.self)
> try container.encode(self.number.description, forKey: .number)
> }
> }
> 
> 
> let foo = Foo(number: Decimal(string: 
> "2.71828182845904523536028747135266249775")!)
> print(foo) // => Foo(number: 2.71828182845904523536028747135266249775)
> 
> let encoder = JSONEncoder()
> let data = try encoder.encode(foo)
> print(String(data: data, encoding: .utf8)!) // => 
> {"number":"2.71828182845904523536028747135266249775"}
> 
> let decoder = JSONDecoder()
> let decoded = try decoder.decode(Foo.self, from: data)
> print(decoded) // => Foo(number: 2.71828182845904523536028747135266249775)
> 
> print(decoded.number == foo.number) // => true
> — Itai
> 
> On 28 Oct 2017, at 11:23, Evtim Papushev via swift-users wrote:
> 
> Hello :)
> 
> I am trying to find a way to parse a number as Decimal without losing the 
> number's precision.
> 
> It seems that the JSON decoder parses it as Double then converts it to 
> Decimal which introduces errors in the parsing. That behavior is in fact 
> incorrect.
> 
> Does anyone know if there is a way to obtain the raw data for this specific 
> field so I can write the conversion code?
> 
> Thanks,
> Evtim
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] Parsing Decimal values from JSON

[Itai Ferber via swift-users]

Hi Evtim,

Just want to give some context for this.
This is due to the fact that `JSONEncoder` and `JSONDecoder` are 
currently based on `JSONSerialization`: when you go to decode some JSON 
data, the data is deserialized using `JSONSerialization`, and then 
decoded into your types by `JSONDecoder`. At the `JSONSerialization` 
level, however, there is no way to know whether a given numeric value is 
meant to be interpreted as a `Double` or as a `Decimal`.


There are subtle differences to decoding as either, so there is no 
behavior that could satisfy all use cases. `JSONSerialization` has to 
make a decision, so if the number could fit losslessly in a `Double`, it 
will prefer that to a `Decimal`. This allows guaranteed precise 
round-tripping of all `Double` values at the cost of different behavior 
when decoding a `Decimal`.


In practice, this might not really matter in the end based on how you 
use the number (e.g. the loss in precision can be so minute as to be 
insignificant) — what is your use case here? And can you give some 
numeric values for which this is problematic for you?


As others have mentioned, one way to guarantee decoding a numeric string 
in a specific way is to actually encode it and decode it as a `String`, 
then convert into a `Decimal` where you need it, e.g.


```swift
import Foundation

struct Foo : Codable {
var number: Decimal

public init(number: Decimal) {
self.number = number
}

private enum CodingKeys : String, CodingKey {
case number
}

public init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: CodingKeys.self)
let stringValue = try container.decode(String.self, forKey: 
.number)

guard let decimal = Decimal(string: stringValue) else {
throw DecodingError.dataCorruptedError(forKey: .number, in: 
container, debugDescription: "Invalid numeric value.")

}

self.number = decimal
}

public func encode(to encoder: Encoder) throws {
var container = encoder.container(keyedBy: CodingKeys.self)
try container.encode(self.number.description, forKey: .number)
}
}


let foo = Foo(number: Decimal(string: 
"2.71828182845904523536028747135266249775")!)

print(foo) // => Foo(number: 2.71828182845904523536028747135266249775)

let encoder = JSONEncoder()
let data = try encoder.encode(foo)
print(String(data: data, encoding: .utf8)!) // => 
{"number":"2.71828182845904523536028747135266249775"}


let decoder = JSONDecoder()
let decoded = try decoder.decode(Foo.self, from: data)
print(decoded) // => Foo(number: 
2.71828182845904523536028747135266249775)


print(decoded.number == foo.number) // => true
```

— Itai

On 28 Oct 2017, at 11:23, Evtim Papushev via swift-users wrote:


Hello :)

I am trying to find a way to parse a number as Decimal without losing 
the number's precision.


It seems that the JSON decoder parses it as Double then converts it to 
Decimal which introduces errors in the parsing. That behavior is in 
fact incorrect.


Does anyone know if there is a way to obtain the raw data for this 
specific field so I can write the conversion code?


Thanks,
Evtim

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

[swift-users] Justification for Swift Design Decisions?

[Michael Rogers via swift-users]

Hi, All:

I’m giving a presentation on Swift this weekend, and am trying to find 
justification for some of the design decisions that they made. Is there 
anything out there that goes into the detail of this? Like … why did the use “ 
for characters, or \() for String interpolation?

Thanks,

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

Re: [swift-users] Finding resources.

[Nate Birkholz via swift-users]

Hi, Moughees. This mailing list is for issues found developing with the
Swift language and not for help with third party frameworks such as Vapor.

Looking at the page for Vapor at https://github.com/vapor/vapor it seems
that they use a Slack channel for support. I would suggest you install a
Slack client and join their channel to get your questions answered.

On Mon, Oct 30, 2017 at 11:53 PM, moughees shah via swift-users <
swift-users@swift.org> wrote:

> I am very new to vapors and no nothing about it. I try to find some
> resources but don't find anything helping. Right now i am assigned to make
> a web form in vapor and because of lack of knowledge I am having trouble.
> I have to submit that as soon as possible.
> Will you please help me out.
>
> Thanks & Regards:
> Moughees Haider.
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>


-- 
Nate Birkholz
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Parsing Decimal values from JSON

[Rimantas Liubertas via swift-users]

>
> Swift shouldn't be forced to adhere to the limitations of JavaScript. Just
> because JS doesn't know about decimals doesn't mean swift can't do better.
>
JSON does not know about decimals either. http://json.org/. If you need
some custom data type you can always pass it as a string and then handle as
needed.

Best regards,
Rimantas
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

[swift-users] Finding resources.

[moughees shah via swift-users]

I am very new to vapors and no nothing about it. I try to find some resources 
but don't find anything helping. Right now i am assigned to make a web form in 
vapor and because of lack of knowledge I am having trouble.
I have to submit that as soon as possible.
Will you please help me out.

Thanks & Regards:
Moughees Haider.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users