2014-02-21 16:18:39 -06:00
|
|
|
// Copyright 2014 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
|
|
|
//! Implementations of serialization for structures found in libcollections
|
|
|
|
|
|
|
|
use std::uint;
|
2014-02-25 10:04:38 -06:00
|
|
|
use std::default::Default;
|
|
|
|
use std::hash::{Hash, Hasher};
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
use std::collections::hash_state::HashState;
|
2014-02-21 16:18:39 -06:00
|
|
|
|
|
|
|
use {Decodable, Encodable, Decoder, Encoder};
|
2014-12-17 09:16:10 -06:00
|
|
|
use std::collections::{DList, RingBuf, BTreeMap, BTreeSet, HashMap, HashSet, VecMap};
|
|
|
|
use collections::enum_set::{EnumSet, CLike};
|
2014-02-21 16:18:39 -06:00
|
|
|
|
|
|
|
impl<
|
2015-01-04 00:24:50 -06:00
|
|
|
T: Encodable
|
|
|
|
> Encodable for DList<T> {
|
|
|
|
fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
s.emit_seq(self.len(), |s| {
|
|
|
|
for (i, e) in self.iter().enumerate() {
|
2014-03-18 12:58:26 -05:00
|
|
|
try!(s.emit_seq_elt(i, |s| e.encode(s)));
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(())
|
2014-02-21 16:18:39 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-04 00:24:50 -06:00
|
|
|
impl<T:Decodable> Decodable for DList<T> {
|
|
|
|
fn decode<D: Decoder>(d: &mut D) -> Result<DList<T>, D::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
d.read_seq(|d, len| {
|
2014-03-18 12:58:26 -05:00
|
|
|
let mut list = DList::new();
|
2015-01-26 14:46:12 -06:00
|
|
|
for i in 0u..len {
|
2014-11-06 11:25:16 -06:00
|
|
|
list.push_back(try!(d.read_seq_elt(i, |d| Decodable::decode(d))));
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(list)
|
|
|
|
})
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-04 00:24:50 -06:00
|
|
|
impl<T: Encodable> Encodable for RingBuf<T> {
|
|
|
|
fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
s.emit_seq(self.len(), |s| {
|
|
|
|
for (i, e) in self.iter().enumerate() {
|
2014-03-18 12:58:26 -05:00
|
|
|
try!(s.emit_seq_elt(i, |s| e.encode(s)));
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(())
|
2014-02-21 16:18:39 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-04 00:24:50 -06:00
|
|
|
impl<T:Decodable> Decodable for RingBuf<T> {
|
|
|
|
fn decode<D: Decoder>(d: &mut D) -> Result<RingBuf<T>, D::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
d.read_seq(|d, len| {
|
2014-03-18 12:58:26 -05:00
|
|
|
let mut deque: RingBuf<T> = RingBuf::new();
|
2015-01-26 14:46:12 -06:00
|
|
|
for i in 0u..len {
|
2014-11-06 11:25:16 -06:00
|
|
|
deque.push_back(try!(d.read_seq_elt(i, |d| Decodable::decode(d))));
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(deque)
|
|
|
|
})
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<
|
2015-01-04 00:24:50 -06:00
|
|
|
K: Encodable + PartialEq + Ord,
|
|
|
|
V: Encodable + PartialEq
|
|
|
|
> Encodable for BTreeMap<K, V> {
|
|
|
|
fn encode<S: Encoder>(&self, e: &mut S) -> Result<(), S::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
e.emit_map(self.len(), |e| {
|
|
|
|
let mut i = 0;
|
|
|
|
for (key, val) in self.iter() {
|
2014-03-18 12:58:26 -05:00
|
|
|
try!(e.emit_map_elt_key(i, |e| key.encode(e)));
|
|
|
|
try!(e.emit_map_elt_val(i, |e| val.encode(e)));
|
2014-02-21 16:18:39 -06:00
|
|
|
i += 1;
|
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(())
|
2014-02-21 16:18:39 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<
|
2015-01-04 00:24:50 -06:00
|
|
|
K: Decodable + PartialEq + Ord,
|
|
|
|
V: Decodable + PartialEq
|
|
|
|
> Decodable for BTreeMap<K, V> {
|
|
|
|
fn decode<D: Decoder>(d: &mut D) -> Result<BTreeMap<K, V>, D::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
d.read_map(|d, len| {
|
2014-12-16 22:09:16 -06:00
|
|
|
let mut map = BTreeMap::new();
|
2015-01-26 14:46:12 -06:00
|
|
|
for i in 0u..len {
|
2014-03-18 12:58:26 -05:00
|
|
|
let key = try!(d.read_map_elt_key(i, |d| Decodable::decode(d)));
|
|
|
|
let val = try!(d.read_map_elt_val(i, |d| Decodable::decode(d)));
|
2014-02-21 16:18:39 -06:00
|
|
|
map.insert(key, val);
|
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(map)
|
2014-02-21 16:18:39 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<
|
2015-01-04 00:24:50 -06:00
|
|
|
T: Encodable + PartialEq + Ord
|
|
|
|
> Encodable for BTreeSet<T> {
|
|
|
|
fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
s.emit_seq(self.len(), |s| {
|
|
|
|
let mut i = 0;
|
|
|
|
for e in self.iter() {
|
2014-03-18 12:58:26 -05:00
|
|
|
try!(s.emit_seq_elt(i, |s| e.encode(s)));
|
2014-02-21 16:18:39 -06:00
|
|
|
i += 1;
|
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(())
|
2014-02-21 16:18:39 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<
|
2015-01-04 00:24:50 -06:00
|
|
|
T: Decodable + PartialEq + Ord
|
|
|
|
> Decodable for BTreeSet<T> {
|
|
|
|
fn decode<D: Decoder>(d: &mut D) -> Result<BTreeSet<T>, D::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
d.read_seq(|d, len| {
|
2014-12-16 22:09:16 -06:00
|
|
|
let mut set = BTreeSet::new();
|
2015-01-26 14:46:12 -06:00
|
|
|
for i in 0u..len {
|
2014-03-18 12:58:26 -05:00
|
|
|
set.insert(try!(d.read_seq_elt(i, |d| Decodable::decode(d))));
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(set)
|
2014-02-21 16:18:39 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<
|
2015-01-04 00:24:50 -06:00
|
|
|
T: Encodable + CLike
|
|
|
|
> Encodable for EnumSet<T> {
|
|
|
|
fn encode<S: Encoder>(&self, s: &mut S) -> Result<(), S::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
let mut bits = 0;
|
|
|
|
for item in self.iter() {
|
|
|
|
bits |= item.to_uint();
|
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
s.emit_uint(bits)
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<
|
2015-01-04 00:24:50 -06:00
|
|
|
T: Decodable + CLike
|
|
|
|
> Decodable for EnumSet<T> {
|
|
|
|
fn decode<D: Decoder>(d: &mut D) -> Result<EnumSet<T>, D::Error> {
|
2014-03-18 12:58:26 -05:00
|
|
|
let bits = try!(d.read_uint());
|
2014-11-06 11:25:16 -06:00
|
|
|
let mut set = EnumSet::new();
|
2015-01-26 14:46:12 -06:00
|
|
|
for bit in 0..uint::BITS {
|
2014-02-21 16:18:39 -06:00
|
|
|
if bits & (1 << bit) != 0 {
|
2014-11-06 11:25:16 -06:00
|
|
|
set.insert(CLike::from_uint(1 << bit));
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(set)
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
impl<K, V, S> Encodable for HashMap<K, V, S>
|
|
|
|
where K: Encodable + Hash< <S as HashState>::Hasher> + Eq,
|
|
|
|
V: Encodable,
|
|
|
|
S: HashState,
|
|
|
|
<S as HashState>::Hasher: Hasher<Output=u64>
|
|
|
|
{
|
2015-01-07 20:53:58 -06:00
|
|
|
fn encode<E: Encoder>(&self, e: &mut E) -> Result<(), E::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
e.emit_map(self.len(), |e| {
|
|
|
|
let mut i = 0;
|
|
|
|
for (key, val) in self.iter() {
|
2014-03-18 12:58:26 -05:00
|
|
|
try!(e.emit_map_elt_key(i, |e| key.encode(e)));
|
|
|
|
try!(e.emit_map_elt_val(i, |e| val.encode(e)));
|
2014-02-21 16:18:39 -06:00
|
|
|
i += 1;
|
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(())
|
2014-02-21 16:18:39 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
impl<K, V, S> Decodable for HashMap<K, V, S>
|
|
|
|
where K: Decodable + Hash< <S as HashState>::Hasher> + Eq,
|
|
|
|
V: Decodable,
|
|
|
|
S: HashState + Default,
|
|
|
|
<S as HashState>::Hasher: Hasher<Output=u64>
|
|
|
|
{
|
|
|
|
fn decode<D: Decoder>(d: &mut D) -> Result<HashMap<K, V, S>, D::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
d.read_map(|d, len| {
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
let state = Default::default();
|
|
|
|
let mut map = HashMap::with_capacity_and_hash_state(len, state);
|
2015-01-26 14:46:12 -06:00
|
|
|
for i in 0u..len {
|
2014-03-18 12:58:26 -05:00
|
|
|
let key = try!(d.read_map_elt_key(i, |d| Decodable::decode(d)));
|
|
|
|
let val = try!(d.read_map_elt_val(i, |d| Decodable::decode(d)));
|
2014-02-21 16:18:39 -06:00
|
|
|
map.insert(key, val);
|
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(map)
|
2014-02-21 16:18:39 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
impl<T, S> Encodable for HashSet<T, S>
|
|
|
|
where T: Encodable + Hash< <S as HashState>::Hasher> + Eq,
|
|
|
|
S: HashState,
|
|
|
|
<S as HashState>::Hasher: Hasher<Output=u64>
|
|
|
|
{
|
2015-01-07 20:53:58 -06:00
|
|
|
fn encode<E: Encoder>(&self, s: &mut E) -> Result<(), E::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
s.emit_seq(self.len(), |s| {
|
|
|
|
let mut i = 0;
|
|
|
|
for e in self.iter() {
|
2014-03-18 12:58:26 -05:00
|
|
|
try!(s.emit_seq_elt(i, |s| e.encode(s)));
|
2014-02-21 16:18:39 -06:00
|
|
|
i += 1;
|
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(())
|
2014-02-21 16:18:39 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
impl<T, S> Decodable for HashSet<T, S>
|
|
|
|
where T: Decodable + Hash< <S as HashState>::Hasher> + Eq,
|
|
|
|
S: HashState + Default,
|
|
|
|
<S as HashState>::Hasher: Hasher<Output=u64>
|
|
|
|
{
|
|
|
|
fn decode<D: Decoder>(d: &mut D) -> Result<HashSet<T, S>, D::Error> {
|
2014-02-21 16:18:39 -06:00
|
|
|
d.read_seq(|d, len| {
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
let state = Default::default();
|
|
|
|
let mut set = HashSet::with_capacity_and_hash_state(len, state);
|
2015-01-26 14:46:12 -06:00
|
|
|
for i in 0u..len {
|
2014-03-18 12:58:26 -05:00
|
|
|
set.insert(try!(d.read_seq_elt(i, |d| Decodable::decode(d))));
|
2014-02-21 16:18:39 -06:00
|
|
|
}
|
2014-03-18 12:58:26 -05:00
|
|
|
Ok(set)
|
2014-02-21 16:18:39 -06:00
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
2014-11-09 10:30:18 -06:00
|
|
|
|
2015-01-04 00:24:50 -06:00
|
|
|
impl<V: Encodable> Encodable for VecMap<V> {
|
|
|
|
fn encode<S: Encoder>(&self, e: &mut S) -> Result<(), S::Error> {
|
2014-11-09 10:30:18 -06:00
|
|
|
e.emit_map(self.len(), |e| {
|
|
|
|
for (i, (key, val)) in self.iter().enumerate() {
|
|
|
|
try!(e.emit_map_elt_key(i, |e| key.encode(e)));
|
|
|
|
try!(e.emit_map_elt_val(i, |e| val.encode(e)));
|
|
|
|
}
|
|
|
|
Ok(())
|
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-04 00:24:50 -06:00
|
|
|
impl<V: Decodable> Decodable for VecMap<V> {
|
|
|
|
fn decode<D: Decoder>(d: &mut D) -> Result<VecMap<V>, D::Error> {
|
2014-11-09 10:30:18 -06:00
|
|
|
d.read_map(|d, len| {
|
|
|
|
let mut map = VecMap::new();
|
2015-01-26 14:46:12 -06:00
|
|
|
for i in 0u..len {
|
2014-11-09 10:30:18 -06:00
|
|
|
let key = try!(d.read_map_elt_key(i, |d| Decodable::decode(d)));
|
|
|
|
let val = try!(d.read_map_elt_val(i, |d| Decodable::decode(d)));
|
|
|
|
map.insert(key, val);
|
|
|
|
}
|
|
|
|
Ok(map)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|