How has std::hash_map!{} been received?

1

I come from Perl, AFAIK the only other language with a (there more powerful) => pair operator. Yet I feel this choice is a huge pity! It’s not compatible with itself, since even in nightly : remains the Debug separator. I guess that will stay, as a change would break backward compatibility. (I dunno, but could see some being tempted to use Debug as a dependency free ok-ish json!() alternative.)

Structs also use :. To me they are kinda the static counterpart to HashMaps. So extending what macros allow, i.e. $($key:expr: $value:expr),*, would be a consistent, non-breaking way forward!

Outside of Rust : is likewise pretty standard, across JSON, YAML, RON, TOON, MAML, EON, and, unrelated but similar, Css.

2

There are a bunch of crates for doing this, for example, map-macro.

I can't tell from your question whether you're asking about this syntax in one of those crates, or maybe you're not aware of the crates, or something else.

3

expr fragments can't be followed by :. You could use a tt fragment for the key though:

use std::collections::HashMap;

#[macro_export]
macro_rules! hash_map {
    {$($k:tt : $v:expr),* $(,)?} => {
        ::std::collections::HashMap::from([$(($k, $v),)*])
    };
}

fn main() {
    let x: HashMap<&'static str, i32> = hash_map! {
        "foo" : 0,
        "bar" : 1,
    };
    
    println!("{x:?}");
}

Playground.

Edit: is this about this RFC?

If so, it predates Rust 1.0. I don't believe there is any traction for getting more macros for collection types into std.

4

I’m very happy that the gap to vec![] is being closed. At the same time, I’m sad that the current (luckily still unstable) proposal feels alien and inconsistent.

So even though nobody asked (it was briefly discussed before the implementation,) this is just my vote on the topic.

5

If you're talking about a Rust proposal or RFC, please link to it.

6

I know, that’s why I said extend, i.e. in the compiler. As for tt, it will not match an expression, e.g. String::from("key"), so it’s hopeless here.

7

I’m talking about the already implemented unstable macro. I added the link above.

8

I think the idea is that many keys are basic, and other cases can be handled by wrapping the expression in parenthesis or braces. It's certainly not ideal though.

I don't mind the => syntax so much; it aligns with match statements at least. My bigger discontentment is with the general state of decl macros at large, which are restricted in such annoying ways.

9

I don’t see matching match statements as a goal for a data description. The => operator is something totally unrelated.

And macro limitations are not only annoying! They can’t even match plain Rust, e.g. if $cond:expr $then:block.

10

Which delimter to use is an explicit open question in that tracking issue (to be resolved before stabilization), and also what most the conversation there and in the ACP is about, so I don't think the subject has been overlooked.

11

Oh, good to know. I was under the impression that with the implementation done, that question just withered away.