On Sat, Mar 1, 2014 at 9:07 PM, Niko Matsakis <n...@alum.mit.edu> wrote:
> On Fri, Feb 28, 2014 at 11:23:23PM -0800, Kevin Ballard wrote: > > I'm also slightly concerned that #[deriving(Data)] gives the > > impression that there's a trait Data, so maybe that should be > > lowercased as in #[deriving(data)], or even just > > #[deriving(builtin)], but this is a lesser concern and somewhat > > bike-sheddy. > > This is definitely bikeshedding, but that's important too. While we're > bikeshedding, I think we ought to rename the trait `Pod`, which > doesn't fit into our "verb" scheme: > > Freeze > Send > Share > Pod > Yes please. It bothers me to no end when an acronym interacts with our camel case naming convention to form a word that's valid English and has nothing at all to do with the original meaning. (The other example is of course `Arc`.) I actually don't really mind if it's `Copy`, `POD`, `PlainOldData`... just not `Pod`. > > My first thought is to resurrect `Copy`, though of course it's very > similar to `Clone`. Anyway, let's assume for now we rename `Pod` to `Copy`. > > In that case, I think I would have the following "trait sets": > > data = Eq, Ord, Clone, Freeze, Hash, Share <-- Note: not Copy! > pod = data, Copy > > The idea is that almost all types (hashtables, etc) can use `data` (in > particular, `data` is applicable to types with `~` pointers). Very > simple types like `Point` can use `pod` (which is, after all, just > "plain old" data). > > > Niko > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
