Add hashmap, hashset, treemap, and treeset macros

[rust-highfive]

Issue by gsingh93
Saturday Jun 07, 2014 at 16:49 GMT

For earlier discussion, see rust-lang/rust#14726

This issue was labelled with: A-syntaxext in the Rust repository

---

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?

[diwic]

For my own part,
My preference is for : above => - colons are used in struct initialisations, arrows in pattern matching. And we're initializing something similar to a struct (somewhat over-simplified, a map is a struct with dynamic keys), we're not pattern matching it. So colon are a better fit with the rest of the language IMO.

Also, I would vote for just getting something ergonomic in for 1.0 and think about optimisations later.
So given this syntax:

    hashmap!("foo": 5, "bar": 8)

Just something that extracts to

    {
        a = Hashmap::new();
        a.insert("foo", 5);
        a.insert("bar", 8);
        a
    }

...would be fine.

[m13253]

My preference is : above =>,
and use {} instead of ().

For example:

hashmap! {"foo": 42, "bar": 64}

This is similar to JSON and Python, and has the same "theme" as vec!, which uses [].

The JSON similarity makes it easier to directly copy a JSON snippet into a Rust code.

And : is also used in structure initialization. => is something used in match and emphasizes the "result" of a pattern.

[Gankra]

I believe { is only supposed to be used for macros that define top-level items like structs, functions, etc.

[blaenk]

Yeah we should really use :.

[aspcartman]

So is there any movement?

[reem]

@aspcartman Not really - a more general abstraction is needed for std, but you could easily land these in a cargo crate.

[sbeckeriv]

Very sorry. I am new to rust. I wanted to create a HashSet with some default values. I found the vec->to_iter->collect pattern and thought it could be nicer. Then i found this thread.

Are macros favored over functions? I would love to see a function on structures like new that took a default object to convert from. Is there something like this?

http://is.gd/I0xsy5

Since you cant overload a method maybe it can use trait bounds? And each struct in the std can define its conversion for each other. If someone wants to have a new conversion they define it for their object?

[bluss]

Macros are never favoured, but that's just the fact if you can solve it with a function, you should. Macros may be the only way to provide this functionality with the features we want, for example avoiding any intermediate extra allocation.

[sbeckeriv]

Thanks @bluss . I now understand that using a function with trait bounds requires a second object to convert from where macros do not. I dont understand macros well enough. At some point they turn in to real code. Can I view what that code is doing?

In this example http://rustbyexample.com/macros/repeat.html how does $y store all the rest of the arguments? Can I write a function that does the same thing? I haven't found an example or documentation for it.

thanks

[bluss]

Sure, you can use rustc -Z unstable-options --pretty expanded SOURCEFILE where SOURCEFILE is one of your files, it will expand uses of macros into code.

$y in that example is inside $( ... ),+ which means it's a repeated variable (separated by comma). Macros use this to support arbitrary many arguments, something rust functions don't.

[bluss]

I published a crate maplit on crates.io with simple type-specific hashmap!{ } and similar macros so that they are finally available.

The : separator is not available to regular macro_rules! macros after an expr, so maplit uses => as key-value separator.

Prior art in this business include generic container literals in literator and generic container literals in grabbag_macros and an older crate with generic container literals called construct.

The generic solutions all have some drawbacks, so I think it's nice to have the type-specific macros out there as well.

[BlacklightShining]

Personally, I would use brackets (since braces are apparently reserved for other things, as Gankro said). Swift uses brackets for array and mapping literals, and I'm sure it's not the only one.

Also, I wonder if this could be generalized to support all Vec-like and mapping types, rather than having separate macros for each one. Something like let hash_map: HashMap<_> = mapping![key1: value1, key2: value2, ...];…maybe even adding syntactic sugar so we don't need a macro?

[nagisa]

Personally, I would use brackets

This is something the user, not implementor, decides. For example all these work and are equivalent:

    let a = vec!{1, 3, 5};
    let b = vec![1, 3, 5];
    let c = vec!(1, 3, 5);

[ticki]

@nagisa, right but there should be a convention.