C++-style initializer list

[bombless]

In C++ you can use an initializer to initialize a map, which looks like a map literal and feels nice.

#include <map>
int main() {
    auto m = std::map<int, int> { { 1, 2 }, { 3, 4 } };
}

playground

So I suggest we can do something like this:

let m = <HashMap<i32, i32>> { // wrapping type name with <> to indicate type like in UFCS
  ( 1, 2 ),
  ( 3, 4 ),
};

which do similar thing as above C++ code.

We already have initializer list built-in so we don't need to tackle about the initializer side.

Let me explain how above Rust code work:
It is desugared to:

let m: HashMap<i32, i32> = vec![(1, 2), (3, 4)].into_iter().collect(); // I hope we can drain array here

playground
The trick is that impl<K, V, S> FromIterator<(K, V)> for HashMap<K, V, S> is done already.

To sum up, points are:

• start with a type here so we know it's about a type, not for the propose of mentioning some associated item and not to start struct literals and such
• wrap a list in braces and separate with comma
• each item in the list is plain expression, so the syntax is very flexible

Now you might argue that if the desugared form is already okay why should we accept this fancy sugar.
I say this sugaring form is much more human-parsable and can make life easier.

[KalitaAlexey]

I'd prefer

hash_map!([i32, i32], 1 => 2, 3 => 4)

hash_map!([i32, i32],
          1 => 2,
          3 => 4)

[bombless]

@KalitaAlexey what I suggest is that we introduce less sugaring, this way the syntax will be more powerful.

For example, my proposal is not about pair, it just happened to involve (U, V), because the list item is (U, V).

This (U, V) can be something else, like plain T.
This way, after we can drain array, maybe after we introduce type-level integer, we can remove vec! macro entirely.

let v: Vec<i32> = <Vec<_>> { 1, 2 };

will be desugared to

let v: Vec<i32> = [1, 2].drain_to_iter().collect();

[KalitaAlexey]

@bombless When we introduce type-level integer generics we could make impl

impl<N, T> From<[T; N]> for Vec<T>

And use it in the following form:

let v: Vec<i32> = [1, 2].into();

I am against this syntax because it adds complexity to parser, developers without any significant profit.

[bombless]

@KalitaAlexey
I'm not sure but

hash_map!([i32, i32],
          1 => 2,
          3 => 4)

looks very ugly.

I will try to implement my syntax.

[KalitaAlexey]

@bombless Uglier than:

<HashMap<i32, i32>> { // wrapping type name with <> to indicate type like in UFCS
  ( 1, 2 ),
  ( 3, 4 ),
};

?

[bombless]

@KalitaAlexey
Well I didn't know you don't like my proposed syntax.

As I mentioned above, initializer list is very powerful, otherwise C++ community won't accept it.

[KalitaAlexey]

@bombless I don't like C++. I am working as C++ programmer, but C++ is ugly. We shouldn't accept any feature from C++ just because it is from C++. Let's wait for another people opinions.

[bombless]

Plus you don't add one macro for each type, that looks insane.

[KalitaAlexey]

@bombless Why not? Why does it look insane?

[bombless]

@KalitaAlexey Macros exist only because type system is not powerful enough.
Let's build a type-riched language and don't look back.

[KalitaAlexey]

Macros exist because it allows many things without extending syntax for each case. Rust will end like C++ with many-many features, but with ugly-ugly syntax.

[KalitaAlexey]

And about type system.
With type-level integer generics we could write

impl<K, V, N> From<[(K, V); N]> for HashMap<K, V>

And use:

let m: HashMap<i32, i32> = [(1, 2), (3, 4)].into();

Without extra syntax.

[bombless]

Like I said,

Now you might argue that if the desugared form is already okay why should we accept this fancy sugar.
I say this sugaring form is much more human-parsable and can make life easier.

You see,

let m: HashMap<i32, i32> = vec![(1, 2), (3, 4)].into_iter().collect();

already looks okay, so I'd suggest macro is off-topic here.

[rphmeier]

I think @KalitaAlexey's integer-generics idea looks pretty nice, and it may be worth just waiting until then.

My main issue with that approach is that it seems to involve pushing the entire array onto the stack and then moving each element into the map individually, which in extreme cases could lead to stack overflow if the optimizer isn't clever enough to figure that out.

How do C++ initializer lists utilize stack space?

[KalitaAlexey]

@rphmeier Same. There is no way to utilize any more efficient.
According to http://www.cplusplus.com/reference/initializer_list/initializer_list