# Vec! like initaliser for other collections **URL:** \ **Category:** ideas (deprecated)\ **Created:** [March 18, 2015, 11:29pm UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730 "2015-03-18T23:29:16Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![mm865](https://avatars.discourse-cdn.com/v4/letter/m/91b2a8/32.png) [@mm865](https://internals.rust-lang.org/u/mm865)\ **Post date:** [March 18, 2015, 11:29pm UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/1 "2015-03-18T23:29:16Z")
Vec has a macro to assist in initialising a Vec with given contents, however none of the other collections in libstd have one. Many other languages have syntax for declaring e.g. a hash map in one go, including Python, Ruby, C++, and C#. Could we do something similar for at least the more commonly used collections, such as HashMap (and maybe others)? I was thinking along these lines: let my\_vec = vec![1, 2, 3]; // this is for Vec let my\_hashmap = hashmap!{“one”: 1, “two”: 2, “three”: 3}; // this is for HashMap I’m not sure if this syntax is possible, but I assume it is as vec! has square brackets instead of parentheses. What are your thoughts? Any other collections this could be useful for? ---
**Author:** ![stebalien](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/stebalien/32/228_2.png) [@stebalien](https://internals.rust-lang.org/u/stebalien)\ **Post date:** [March 19, 2015, 5:10am UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/2 "2015-03-19T05:10:33Z")
I believe there have been talks about a generic `seq!` macro: ```rust let my_vec: Vec<_> = seq![1,2,3]; let my_map: HashMap<_, _> = seq! { "a" => 1, "b" => 2 }; ``` Under the covers, this would be implemented using collect: ```rust macro_rules! seq { ($($k:expr => $v:expr),*) => { .collect() }; ($($(v:expr),*) => { .collect() }; } ``` ---
**Author:** ![llogiq](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/llogiq/32/13692_2.png) [@llogiq](https://internals.rust-lang.org/u/llogiq)\ **Post date:** [March 19, 2015, 8:49am UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/3 "2015-03-19T08:49:57Z")
I somewhat dislike the `x => y` syntax. It has no precedence within Rust, and it reminds me of Perl (or Ruby, if I’m feeling generous). We should take care not to re-use any operator that could be used inside keys or values. Thus, I can see the following alternatives: - `x=y` (Lua) has the benefit of looking like an assignment within the namespace of the map, at the cost of looking like an assignment. Since we would not want to mix assignments and our macro, it would be ok to re-use the `=` operator. - `x:y` (JSON, python, just about everywhere) has the benefit of not looking like an assignment and being familiar to the huge group of python/Javascipt/…etc. developers at the cost of looking like a Rust type declaration. - `x->y` looks like a bastardization of a function and a binding and like `=>` takes two sigils, but (IMHO) looks a bit cleaner and cannot be confused with either an assignment or a type declaration. ---
**Author:** ![mm865](https://avatars.discourse-cdn.com/v4/letter/m/91b2a8/32.png) [@mm865](https://internals.rust-lang.org/u/mm865)\ **Post date:** [March 19, 2015, 12:00pm UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/4 "2015-03-19T12:00:36Z")
I actually quite like “=\>” for the syntax. It is already used in matching, and this has similar semantics - match “one” with 1. I dislike the others, especially the second as you wouldn’t be able to include type decelerations in the list, and the third as you couldn’t use lambdas with explicit return types. The first one looks too much like assignment for me. ---
**Author:** ![llogiq](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/llogiq/32/13692_2.png) [@llogiq](https://internals.rust-lang.org/u/llogiq)\ **Post date:** [March 19, 2015, 2:51pm UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/5 "2015-03-19T14:51:12Z")
Agreed, the =\> syntax is used for pattern matching. Ok, so there _is_ some precedence in Rust, I’m gonna retract my statement; I guess I can live with it. 😄 ---
**Author:** ![mdinger](https://avatars.discourse-cdn.com/v4/letter/m/97f17d/32.png) [@mdinger](https://internals.rust-lang.org/u/mdinger)\ **Post date:** [March 19, 2015, 4:55pm UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/6 "2015-03-19T16:55:47Z")
There’s an [RFC](https://github.com/rust-lang/rfcs/pull/207) for `seq![]`. ---
**Author:** ![mm865](https://avatars.discourse-cdn.com/v4/letter/m/91b2a8/32.png) [@mm865](https://internals.rust-lang.org/u/mm865)\ **Post date:** [March 20, 2015, 12:54am UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/7 "2015-03-20T00:54:42Z")
Hmmm. I suppose it would be entirely backwards compatible, except that vec! would probably be removed. That would mean it needs to be done before or after 1.x. ---
**Author:** ![Gankra](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gankra/32/6002_2.png) [@Gankra](https://internals.rust-lang.org/u/Gankra)\ **Post date:** [March 20, 2015, 3:19am UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/8 "2015-03-20T03:19:46Z")
I doubt vec! will ever be removed. ---
**Author:** ![mm865](https://avatars.discourse-cdn.com/v4/letter/m/91b2a8/32.png) [@mm865](https://internals.rust-lang.org/u/mm865)\ **Post date:** [March 20, 2015, 6:20am UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/9 "2015-03-20T06:20:31Z")
It would break a huge amount of code, but assuming seq! is the same syntax - I think it is (?) based on above comments - then a simple find and replace would fix it ---
**Author:** ![llogiq](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/llogiq/32/13692_2.png) [@llogiq](https://internals.rust-lang.org/u/llogiq)\ **Post date:** [March 20, 2015, 8:20am UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/10 "2015-03-20T08:20:37Z")
Perhaps go the Java route and deprecate vec! in 1.1 and remove it in 7.5 or something? 😄 ---
**Author:** ![Gankra](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gankra/32/6002_2.png) [@Gankra](https://internals.rust-lang.org/u/Gankra)\ **Post date:** [March 21, 2015, 1:27pm UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/11 "2015-03-21T13:27:37Z")
vec! is strictly better than seq! though; seq requires type hints for the type of collection, while vec doesn’t. (vec might still need type hints for the contents, but this is quite rare in my experience, particularly with integer fallback) ---
**Author:** ![llogiq](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/llogiq/32/13692_2.png) [@llogiq](https://internals.rust-lang.org/u/llogiq)\ **Post date:** [March 21, 2015, 10:19pm UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/12 "2015-03-21T22:19:14Z")
On the same note, would it make sense to split the macro to `map!` and `tree!` or something similar? ---
**Author:** ![kstep](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kstep/32/851_2.png) [@kstep](https://internals.rust-lang.org/u/kstep)\ **Post date:** [March 23, 2015, 6:53am UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/13 "2015-03-23T06:53:00Z")
I a actually have `map!()` macro somewhere in depth of my code. But I like universal approach of `seq!()`: I have terrible memory, and the less things to remember, three better. ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [March 25, 2019, 8:24am UTC](https://internals.rust-lang.org/t/vec-like-initaliser-for-other-collections/1730/14 "2019-03-25T08:24:05Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.