Add hashmap, hashset, treemap, and treeset macros

[gsingh93]

I wanted to create an issue first asking about this before submitting a pull request.

Can I go ahead an implement hashmap!(), hashset!(), treemap!(), and treeset!() macros for constructing those collections with the given arguments? The syntax would be:

let h = hashmap!("foo" => "bar");
let s = hashset!("foo");

I already have these macros implemented in my own projects, so I'd just have to add them to macros.rs.

If I can add these, is there a process for testing macros? Or would I just replace all occurrences of hash{map,set} and tree{map,set} creation in the tests by the macros?

[TyOverby]

One problem that I can see off the top of my head is that macros.rs is in the std crate, while all the collections that you are using are in the collections crate. I'm not sure if you could add macros to the collections crate.

I am strongly in favor of getting these macros added somewhere simply because of how common the collections are used. We need a shortcut.

[schmee]

If this gets added, I'm strongly in favor of using : instead of => in the map macros since it's

• shorter
• easier to type
• precedent from Python, Go, Dart, JSON, and even Ruby since 1.9 (and probably others)

[TyOverby]

If this gets added, I'm strongly in favor of using : instead of =>

I'm not so sure about this. Colons are already used for type annotations and namespaces. I think -> or => are perfectly acceptable.

[gsingh93]

@TyOverby Didn't the collections get moved to std?

I'm fine with either syntax.

[TyOverby]

Didn't the collections get moved to std?

Oh wow, they totally did. I wonder if Vec will get moved there too?

[huonw]

Vec has always been accessible via std?

In any case, I think this is a change that requires an RFC. I would prefer having a generic macro (or two of them) that allows constructing any container type, rather than having to manually create one for each type and forcing other data structure implementers to do the same.

[TyOverby]

Vec has always been accessible via std

I meant in std::collections, but I suppose it's more useful in core.

[gsingh93]

@huonw How would that generic macro figure out the type of container to create? Would you have to pass in the type?

I can create an RFC if no one else wants to (note: I don't want to, I wouldn't be able to comment on implementation at all).

[huonw]

Using traits, something like

trait Seq<T>: Default {
    fn add_elem(&mut self, x: T);
}

macro_rules! seq {
    ($($e: expr),*) => {{
        let mut _thing = Default::default();
        $( _thing.add_elem($e); )*
        _thing
    }}
}

let s: HashSet<int> = seq!(1, 2, 3); // HashSet impls Seq<int>
let s: HashMap<int, int> = seq!((1, 10), (2, 20), (3, 30); // impls Seq<(int, int)>

(I don't have time to write an RFC atm, maybe in a week and a half.)

[gsingh93]

Ah, I see. I'll post in this thread next week then to ask about the RFC unless anyone else gets around to writing it.

[gereeter]

Isn't seq! already implementable using the FromIterator trait?

[huonw]

@gereeter yes, but it would be quite ineffficient.

[tomjakubowski]

@huonw Would that macro work? I tried to write a similar one for the MutableMap trait which wouldn't type check because the type of _thing must be known at the insert:

#![feature(macro_rules)]

extern crate collections;

macro_rules! map {
    ($($k: expr => $v: expr),*) => {{
        use std::default::Default;

        let mut _thing = Default::default();
        $( _thing.insert($k, $v); )* //~ ERROR the type of this value must be known in this context
        _thing
    }}
}

pub fn main() {
    use collections::treemap::TreeMap;

    let x: TreeMap<int, int> = map!(1 => 2);
}

[huonw]

Ah, looks like Rust's current type inference might not be powerful enough (I have no idea if we extend it to make it work).

Something like ($ty: type: $($k: expr ... )) expanding to let mut _thing: $ty = ... might work; used like map!(TreeMap<int, int>: 1 => 2).

(With this, even map!(TreeMap<_, _>: 1 => 2) might work.)