diff options
| author | Alex Crichton <alex@alexcrichton.com> | 2017-09-16 09:16:48 -0500 |
|---|---|---|
| committer | Alex Crichton <alex@alexcrichton.com> | 2017-09-16 17:09:37 -0700 |
| commit | 256b8879ccb0c790e41778dd605c9abe81806a55 (patch) | |
| tree | 70ea02574068f9f5fe4d0ec03f009e0921f636ef /src/test/incremental/thinlto | |
| parent | 48193c2fe00e630bed3c989e479e7be437c4c133 (diff) | |
| parent | 9d5b0e1ff54198543233f418fbc43921b5f7201b (diff) | |
| download | rust-256b8879ccb0c790e41778dd605c9abe81806a55.tar.gz rust-256b8879ccb0c790e41778dd605c9abe81806a55.zip | |
Rollup merge of #44395 - jcdyer:ip-constructors, r=alexcrichton
Ipv4Addr and Ipv6Addr convenience constructors. Introduce convenience constructors for common types. This introduces the following constructors: * Ipv6Addr::localhost() * Ipv6Addr::unspecified() * Ipv4Addr::localhost() * Ipv4Addr::unspecified() The recently added `From` implementations were nice for avoiding the fallibility of conversions from strings like `"127.0.0.1".parse().unwrap()`, and `"::1".parse().unwrap()`, but while the Ipv4 version is roughly comparable in verbosity, the Ipv6 version lacks zero-segment elision, which makes it significantly more awkward: `[0, 0, 0, 0, 0, 0, 0, 0].into()`. While there isn't a clear way to introduce zero elision to type that can infallibly be converted into Ipv6 addresses, this PR resolves the problem for the two most commonly used addresses, which, incidentally, are the ones that suffer the most from the lack of zero-segment elision. This change is dead simple, and introduces no backwards incompatibility. See also, [this topic on the inernals board](https://internals.rust-lang.org/t/pre-rfc-convenience-ip-address-constructors/5878)
Diffstat (limited to 'src/test/incremental/thinlto')
0 files changed, 0 insertions, 0 deletions