GitHub PushEvent at 2014-12-09 20:18:58
Repository: rust
Actor: alfie
Payload: {"shas":[["ca4f53655e82a0a0e1d613b16108720bb7a50fde","12c875436a19b99bf0b96f0110d54611e83c2b9b@barosl.com","libserialize: Remove float preprocessing in serialize::json::Encoder\n\nserialize::json::Encoder currently uses f64 to emit any integral type.\nThis is possibly due to the behavior of JavaScript, which uses f64 to\nrepresent any numeric value.\n\nThis leads to a problem that only the integers in the range of [-2^53+1,\n2^53-1] can be encoded. Therefore, i64 and u64 cannot be used reliably\nin the current implementation.\n\nRFC 7159 suggests that good interoperability can be achieved if the\nrange is respected by implementations. However, it also says that\nimplementations are allowed to set the range of number accepted. And it\nseems that the JSON encoders outside of the JavaScript world usually\nmake use of i64 values.\n\nThis commit removes the float preprocessing done in the emit_* methods.\nIt also increases performance, because transforming f64 into String\ncosts more than that of an integral type.\n\nFixes #18319\n\n[breaking-change]","Barosl Lee",true],["f102123b659911dbee25bbe518d73d66185bb978","12c875436a19b99bf0b96f0110d54611e83c2b9b@barosl.com","libserialize: Do not coerce to integer when decoding a float value\n\nWhen an integral value is expected by the user but a fractional value is\nfound, the current implementation uses std::num::cast() to coerce to an\ninteger type, losing the fractional part. This behavior is not desirable\nbecause the number loses precision without notice.\n\nThis commit makes it raise ExpectedError when such a situation arises.\n\n[breaking-change]","Barosl Lee",true],["fec0f16c98ab066ff11be35b5a8bb0d80efa90f1","12c875436a19b99bf0b96f0110d54611e83c2b9b@barosl.com","libserialize: Always use a decimal point when emitting a float value\n\nJSON doesn't distinguish between integer and float. They are just\nnumbers. Also, in the current implementation, a fractional number\nwithout the fractional part is encoded without a decimal point.\n\nThereforce, when the value is decoded, it is first rendered as Json,\neither I64 or U64. This reduces type safety, because while the original\nintention was to cast the value to float, it can also be casted to\ninteger.\n\nAs a workaround of this problem, this commit makes the encoder always\nemit a decimal point even if it is not necessary. If the fractional part\nof a float number is zero, \".0\" is padded to the end of the result.\n\n[breaking-change]","Barosl Lee",true],["c32286d1b1f1494cf46fb6403e329e7bb6d31942","12c875436a19b99bf0b96f0110d54611e83c2b9b@barosl.com","libserialize: Code cleanup","Barosl Lee",true],["7176dd1c9039d7d10c0ceb694b929d094cc299e3","12c875436a19b99bf0b96f0110d54611e83c2b9b@barosl.com","libserialize: Prefer into_string() to to_string() wherever possible\n\nExcept for the example code!","Barosl Lee",true],["87edbea9da1d7dfd7e8c68e15f846f08d5f3a8c0","4cc33a8ae3d9bb448f90bf63a1d4018698b1fb94@alum.mit.edu","Add ability to configure recursion limit.\n\nFixes #19318.","Niko Matsakis",true],["3ee85d828ebb2502d186ff63f0215340bf79d5ad","4cc33a8ae3d9bb448f90bf63a1d4018698b1fb94@alum.mit.edu","Kill dead code","Niko Matsakis",true],["34812b891db7a699cebddb584e6c6ae44f82ed2e","4cc33a8ae3d9bb448f90bf63a1d4018698b1fb94@alum.mit.edu","Stop masking overflow and propagate it out more aggressively; also improve error reporting to suggest to user how to fix.","Niko Matsakis",true],["cafe2966770ff377aad6dd9fd808e68055587c58","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #19249 : barosl/rust/json-type-safety, r=alexcrichton\n\nThis pull request tries to improve type safety of `serialize::json::Encoder`.\r\n\r\nLooking at #18319, I decided to test some JSON implementations in other languages. The results are as follows:\r\n\r\n* Encoding to JSON\r\n\r\n| Language | 111111111111111111 | 1.0 |\r\n| --- | --- | --- |\r\n| JavaScript™ | \"111111111111111100\" | \"1\" |\r\n| Python | \"111111111111111111\" | **\"1.0\"** |\r\n| Go | \"111111111111111111\" | \"1\" |\r\n| Haskell | \"111111111111111111\" | \"1\" |\r\n| Rust | **\"111111111111111104\"** | \"1\" |\r\n\r\n* Decoding from JSON\r\n\r\n| Language | \"1\" | \"1.0\" | \"1.6\" |\r\n| --- | --- | --- | --- |\r\n| JavaScript™ | 1 (Number) | 1 (Number) | 1.6 (Number) |\r\n| Python | 1 (int) | 1.0 (float) | 1.6 (float) |\r\n| Go | **1 (float64)** | 1 (float64) | 1.6 (float64) |\r\n| Go (expecting `int`) | 1 (int) | **error** | error |\r\n| Haskell (with `:: Int`) | 1 (Int) | 1 (Int) | **2 (Int)** |\r\n| Haskell (with `:: Double`) | 1.0 (Double) | 1.0 (Double) | 1.6 (Double) |\r\n| Rust (with `::<int>`) | 1 (int) | 1 (Int) | **1 (Int)** |\r\n| Rust (with `::<f64>`) | 1 (f64) | 1 (f64) | 1.6 (f64) |\r\n\r\n* The tests on Haskell were done using the [json](http://hackage.haskell.org/package/json) package.\r\n* The error message printed by Go was: `cannot unmarshal number 1.0 into Go value of type int`\r\n\r\nAs you see, there is no uniform behavior. Every implementation follows its own principle. So I think it is reasonable to find a desirable set of behaviors for Rust.\r\n\r\nFirstly, every implementation except the one for JavaScript is capable of handling `i64` values. It is even practical, because [Twitter API uses an i64 number to represent a tweet ID](https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake), although it is recommended to use the string version of the ID.\r\n\r\nSecondly, looking into the Go's behavior, implicit type conversion is not allowed in their decoder. If the user expects an integer value to follow, decoding a float value will raise an error. This behavior is desirable in Rust, because we are pleased to follow the principles of strong typing.\r\n\r\nThirdly, Python's JSON module forces a decimal point to be printed even if the fractional part does not exist. This eases the distinction of a float value from an integer value in JSON, because by the spec there is only one type to represent numbers, `Number`.\r\n\r\nSo, I suggest the following three breaking changes:\r\n\r\n1. Remove float preprocessing in serialize::json::Encoder\r\n\r\n `serialize::json::Encoder` currently uses `f64` to emit any integral type. This is possibly due to the behavior of JavaScript, which uses `f64` to represent any numeric value.\r\n\r\n This leads to a problem that only the integers in the range of [-2^53+1, 2^53-1] can be encoded. Therefore, `i64` and `u64` cannot be used reliably in the current implementation.\r\n\r\n [RFC 7159](http://tools.ietf.org/html/rfc7159) suggests that good interoperability can be achieved if the range is respected by implementations. However, it also says that implementations are allowed to set the range of number accepted. And it seems that the JSON encoders outside of the JavaScript world usually make use of `i64` values.\r\n\r\n This commit removes the float preprocessing done in the `emit_*` methods. It also increases performance, because transforming `f64` into String costs more than that of an integral type.\r\n\r\n Fixes #18319\r\n\r\n2. Do not coerce to integer when decoding a float value\r\n\r\n When an integral value is expected by the user but a fractional value is found, the current implementation uses `std::num::cast()` to coerce to an integer type, losing the fractional part. This behavior is not desirable because the number loses precision without notice.\r\n\r\n This commit makes it raise `ExpectedError` when such a situation arises.\r\n\r\n3. Always use a decimal point when emitting a float value\r\n\r\n JSON doesn't distinguish between integer and float. They are just numbers. Also, in the current implementation, a fractional number without the fractional part is encoded without a decimal point.\r\n\r\n Thereforce, when the value is decoded, it is first rendered as `Json`, either `I64` or `U64`. This reduces type safety, because while the original intention was to cast the value to float, it can also be casted to integer.\r\n\r\n As a workaround of this problem, this commit makes the encoder always emit a decimal point even if it is not necessary. If the fractional part of a float number is zero, \".0\" is padded to the end of the result.","bors",true],["ef4982f0f8643af9e7deede95ad5e4e8df854d66","3a2c29237f73c7cf88424b80e427b1884f346b35@rust-lang.org","auto merge of #19466 : nikomatsakis/rust/recursion-limit, r=eddyb\n\nThis is particularly important for deeply nested types, which generate deeply nested impls. This is a fix for #19318. It's possible we could also improve this particular case not to increment the recursion count, but it's worth being able to adjust the recursion limit anyhow.\r\n\r\ncc @jdm \r\nr? @pcwalton","bors",true],["b9c3b5693ad599dafa64559089f92233015dd633","009d2fc58d691be6ebb485dcd59bce8a9d646f21@fastmail.fm","doc: grammar fix","Alfie John",true]],"size":11,"ref":"refs/heads/master","head":"b9c3b5693ad599dafa64559089f92233015dd633"}