cafe296677
This pull request tries to improve type safety of `serialize::json::Encoder`. Looking at #18319, I decided to test some JSON implementations in other languages. The results are as follows: * Encoding to JSON | Language | 111111111111111111 | 1.0 | | --- | --- | --- | | JavaScript™ | "111111111111111100" | "1" | | Python | "111111111111111111" | **"1.0"** | | Go | "111111111111111111" | "1" | | Haskell | "111111111111111111" | "1" | | Rust | **"111111111111111104"** | "1" | * Decoding from JSON | Language | "1" | "1.0" | "1.6" | | --- | --- | --- | --- | | JavaScript™ | 1 (Number) | 1 (Number) | 1.6 (Number) | | Python | 1 (int) | 1.0 (float) | 1.6 (float) | | Go | **1 (float64)** | 1 (float64) | 1.6 (float64) | | Go (expecting `int`) | 1 (int) | **error** | error | | Haskell (with `:: Int`) | 1 (Int) | 1 (Int) | **2 (Int)** | | Haskell (with `:: Double`) | 1.0 (Double) | 1.0 (Double) | 1.6 (Double) | | Rust (with `::<int>`) | 1 (int) | 1 (Int) | **1 (Int)** | | Rust (with `::<f64>`) | 1 (f64) | 1 (f64) | 1.6 (f64) | * The tests on Haskell were done using the [json](http://hackage.haskell.org/package/json) package. * The error message printed by Go was: `cannot unmarshal number 1.0 into Go value of type int` As 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. Firstly, 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. Secondly, 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. Thirdly, 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`. So, I suggest the following three breaking changes: 1. Remove float preprocessing in serialize::json::Encoder `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. 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. [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. 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. Fixes #18319 2. Do not coerce to integer when decoding a float value 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. This commit makes it raise `ExpectedError` when such a situation arises. 3. Always use a decimal point when emitting a float value 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. 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. 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.
The Rust Programming Language
This is a compiler for Rust, including standard libraries, tools and documentation.
Quick Start
- Download a binary installer for your platform.
- Read the guide.
- Enjoy!
Note: Windows users can read the detailed using Rust on Windows notes on the wiki.
Building from Source
-
Make sure you have installed the dependencies:
g++4.7 orclang++3.xpython2.6 or later (but not 3.x)perl5.0 or later- GNU
make3.81 or later curlgit
-
Download and build Rust:
You can either download a tarball or build directly from the repo.
To build from the tarball do:
$ curl -O https://static.rust-lang.org/dist/rust-nightly.tar.gz $ tar -xzf rust-nightly.tar.gz $ cd rust-nightlyOr to build from the repo do:
$ git clone https://github.com/rust-lang/rust.git $ cd rustNow that you have Rust's source code, you can configure and build it:
$ ./configure $ make && make installNote: You may need to use
sudo make installif you do not normally have permission to modify the destination directory. The install locations can be adjusted by passing a--prefixargument toconfigure. Various other options are also supported, pass--helpfor more information on them.When complete,
make installwill place several programs into/usr/local/bin:rustc, the Rust compiler, andrustdoc, the API-documentation tool. -
Read the guide.
-
Enjoy!
Building on Windows
To easily build on windows we can use MSYS2:
-
Grab the latest MSYS2 installer and go through the installer.
-
Now from the MSYS2 terminal we want to install the mingw64 toolchain and the other tools we need.
$ pacman -S mingw-w64-i686-toolchain $ pacman -S base-devel -
With that now start
mingw32_shell.batfrom where you installed MSYS2 (i.e.C:\msys). -
From there just navigate to where you have Rust's source code, configure and build it:
$ ./configure $ make && make install
Notes
Since the Rust compiler is written in Rust, it must be built by a precompiled "snapshot" version of itself (made in an earlier state of development). As such, source builds require a connection to the Internet, to fetch snapshots, and an OS that can execute the available snapshot binaries.
Snapshot binaries are currently built and tested on several platforms:
- Windows (7, 8, Server 2008 R2), x86 and x86-64 (64-bit support added in Rust 0.12.0)
- Linux (2.6.18 or later, various distributions), x86 and x86-64
- OSX 10.7 (Lion) or greater, x86 and x86-64
You may find that other platforms work, but these are our officially supported build environments that are most likely to work.
Rust currently needs about 1.5 GiB of RAM to build without swapping; if it hits swap, it will take a very long time to build.
There is a lot more documentation in the wiki.
Getting help and getting involved
The Rust community congregates in a few places:
- StackOverflow - Get help here.
- /r/rust - General discussion.
- discuss.rust-lang.org - For development of the Rust language itself.
License
Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.
See LICENSE-APACHE, LICENSE-MIT, and COPYRIGHT for details.