Tracking Issue for `hash_map!` macro

[stifskere]

View all comments

Feature gate: #![feature(hash_map_macro)]

This is a tracking issue for rust-lang/libs-team#578

The hash_map! macro is like the vec! macro but for HashMaps, it aims to help create hash_maps with set keys for functions that require dynamic key value pairs such as a templating engine asking to fill the templates with a HashMap.

Public API

use std::hash_map;

fn main() {
    let map = hash_map! {
        "key" => "value",
        "key2" => "value2"
    }; // uses type inference.

    for (key, value) in map {
        println!("{key:?} => {value:?}");
    }
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• Implementation: Implement hash_map macro  #144070
• Reverted in Revert "feat: implement hash_map! macro" #148049 due to regression: hashmap macro stuff #147971
• Re-implemented in feat: reimplement hash_map! macro #154322
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• What separator should we use? the main proposition was =>, : was also proposed.
• Should this macro allow using other hashers in it's syntax? If so, how?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[knickish]

Why not use comma separated tuples instead of a new separator?

[hanna-kruppe]

You mean as in hash_map!{(key1, val1), (key2, val2), …}? You can already do HashMap::from([(key1, val1), (key2, val2), …]) with a similar density of punctuation, the point of the macro is significantly more lightweight syntax than is possible without a macro.

[chikof]

I think the : operator feels off, as it is normally used for type annotations and structure definitions, while the => operator is Rust's idiomatic choice and feels right.

[zkldi]

There's some prior art for =>, the sorta popular common_macros crate uses => as the separator for an equivalent macro.

[mehcode]

The maplit crate uses => as a separator with 72,693,071 all-time downloads, so there is definitely some precedence here.

---

Some languages that use an arrow (ish) symbol for associative array creation:

• Ceylon (uses ->)
• Julia
• Kotlin (uses to)
• PHP
• Ruby
• Scala (uses ->)

---

As for Rust, I think there are a few palatable options:

1. Use :. Requires language changes to allow : in macros after expressions (or a built-in macro).

   hash_map!{ "x": 20, "y": 30 }

   This is my favorite as it lines up with how structure initialization works as well as another very commonly used "map" macro ( serde_json::json! ).

   I understand the comments around this looking like type annotations but I think the ship has sailed on that with : being used in structure initialization.

2. Use =>. Change the Debug output of HashMap to this to match (Debug output isn't stable so this should be fine I think).

   hash_map!{ "x" => 20, "y" => 30 }

   One neat thing that Kotlin does with x to y is define that as a general infix expression to create a 2-tuple. This could allow for something like this:

   HashMap::from([ "x" => 10, "y" => 20 ])

   which would simplify the macro implementation a bit and eventually allow for an expression like HashMap::new("x" => 20, "y" => 20, ...) once variable-length arguments exist.

3. Use =. Visually I think this is the best.

   hash_map!{ "x" = 20, "y" = 30 }

   It's unfortunate that struct initialization uses : as it would be nice for the parallel to exist.

   However note that named arguments will likely use = (println! being the stable example which I imagine will eventually get lifted into syntax) so I could imagine a future where something like this works without the macro:

   HashMap::new(x = 20, y = 30)

[izik1]

Regardless of anything else, I think that hash_map![..] to fit with vec! makes more stylistic sense than using hash_map! { .. }, this is technically possible regardless of how the macro is documented because macros can use {} () or [] interchangeably, but convention matters, and IMHO defaulting to [] makes more sense in the context of std.

[stifskere]

Regardless of anything else, I think that hash_map![..] to fit with vec! makes more stylistic sense than using hash_map! { .. }, this is technically possible regardless of how the macro is documented because macros can use {} () or [] interchangeably, but convention matters, and IMHO defaulting to [] makes more sense in the context of std.

I wrote it that way because HashMaps could potentially be more associated to objects than arrays, in JavaScript an object and a map is the same really. In rust not, but structs, and any map-like structure are both "keys associated to values"