Add map! and set! macros to std

[burntsushi]

@CAD97

left-pad is not notable for being a microlibrary for functionality that could have been std. It's notable for being a widely used (micro)library which disappeared, breaking the ecosystem. cratesio dependencies cannot be disappeared in that manner; the comparison is at best disingenuous.

It's at least both IMO. Certainly nowhere near disingenuous. For many folks, left-pad serves as an indicator for when dependencies get out of control. That can be true while it being simultaneously true that left-pad broke the ecosystem because it was allowed to be removed in the first place.

(I personally try to be more direct and just say "proliferation of micro crates," which I think is pretty clearly what is meant here.)

[afetisov]

There were two good reasons to have the vec! macro:

• It mirrors the syntax for arrays. Where one would write [a; n], one could instead write vec![a; n] and get a vector. This is also a simple workaround for most cases where a is Clone but not Copy. Similarly, one can turn a static array [a, b, c] into a dynamic array just by prefixing it with vec!, i.e. vec![a, b, c].

  From a learning perspective, this draws a nice parallel between static and dynamic arrays. The syntax is almost the same, which also means it's easy to switch between fixed-size static and variable-size dynamic allocation whenever one changes their mind.

• Until a few years ago, arrays were not IntoIterator. This means that the simplest way to iterate by-value over a given sequence was to construct a vector. Code like

  for x in vec![a, b, c] { .. }
  

  was all over the place. Inefficient? Maybe, but it's simple, and the allocation likely won't matter. Similarly, vec![..] would be passed around whenever one needed to pass IntoIterator<Item=T>.

  Now that arrays are iterable, this case no longer applies, but it was important for a long time.

None of these reasons apply to map literals, so I'd say the case for them is very weak. It's not like people construct raw map literals all over the place, like with vec![..] iterators. The case is very niche. Many cases which would be served by map literals in other languages, like JSON objects, use their own custom mapping types and their own macros.

So the win is basically a few less characters to type (O(1)), in turn complicating the api of std and possibly introducing ambiguity (if the same map! macro is supposed to create several types of maps). I'd say it's clearly not worth it.

[Ratatouille]

Adding a map macro clearly will not complicate the api, It's adding a very basic and self explanatory functionality.

As for the ambiguity around map! I agree, It should be hmap and bmap (and hset and bset) this way we get more functionality and less ambiguity.

[Nemo157]

@afetisov

So the win is basically a few less characters to type (O(1))

No, the win is more readable code. The few extra characters also come with very undesirable rustfmt formatting making the code needlessly hard to read.

[scottmcm]

@Nemo157

The few extra characters also come with very undesirable rustfmt formatting making the code needlessly hard to read.

What rustfmt does isn't a law of the universe, especially since getting rustfmt to format the macro nicely would also presumably be a code change to rustfmt.

If everyone says that the way rustfmt handles pairs is poor, that sounds like a good bug to file to fix in a future formatting edition. I know they're talking about one right now.

[Nemo157]

I think the way rustfmt handles pairs is fine normally, large literals of [(K, V)] are uncommon except when being used with maps.

[DDOtten]

Adding macros also allows the more distinctive notation of key => value, like the hashmap_macro crate:

let m: HashMap<&str, u32> = hashmap! {
    "a" => 1,
    "b" => 2,
};

[canndrew]

+1 to copy-pasting the maplit crate into std::collections. This is one of those crates that I import fairly frequently since it just makes code clearer and nicer. In general, any crate which extends the standard library types with small, uncontroversially-designed features should be strongly considered for merging into std. Don't make us reach for third-party libs for trivial stuff like this.

[pitaj]

@Nemo157

For one, style, in realistic code rustfmt makes arrays of tuples very verbose and difficult to read (which is why the macro doesn't use tuples)

HashMap::from_iter([
    (
        dimension::Kind::Overworld,
        Dimension {
            persistent: vec![PersistentArea::Square { .. }],
        },
    ),
    (
        dimension::Kind::Nether,
        Dimension {
            persistent: vec![PersistentArea::Square { .. }],
        },
    ),
])

With overflow_delimited_expr = true in rustfmt.toml, I guess this formatting instead:

HashMap::from_iter([
    (dimension::Kind::Overworld, Dimension {
        persistent: vec![PersistentArea::Square { .. }],
    }),
    (dimension::Kind::Nether, Dimension {
        persistent: vec![PersistentArea::Square { .. }],
    }),
]);

I believe the consensus is to make that the default behavior in edition 2024, so does that resolve the biggest issue here?

[jdahlstrom]

We just need to make a => b another way to spell the 2-tuple constructor (a, b) and we're done

Scala actually does it like that via its prelude adding an extension method named -> to all types…