Support a Set literal syntax

[sethladd]

Sets are very helpful, it would be nice to have a set literal syntax (like the [] for lists and {} for maps) for more terse code.

[gbracha]

Set owner to @gbracha.
Added this to the Later milestone.
Added Accepted label.

[DartBot]

This comment was originally written by @seaneagan

---

another reason: without this there is no way to create a "const" Set, so you are forced to use a List when you need a constant.

[whesse]

I have run up against this problem also, and have wanted a const Set. I have used a map with null values instead.

[DartBot]

This comment was originally written by [email protected]

---

without this there is no way to create a "const" Set

Yep, I just ran into this as well.

There is a workaround however, better than using a List, I think:

    static final Set<String> units = new Set<String>.from(['em','pt','px','%']);

[kevmoo]

Be careful exposing a normal set directly, as it's mutable.

Consider UnmodifiableSetView
https://api.dartlang.org/apidocs/channels/stable/#collection/dart-pkg-collection.UnmodifiableSetView

This is where having literal syntax + const would be great.

[DartBot]

This comment was originally written by [email protected]

---

In my case it's package-internal, so I'm no concerned.

[kasperl]

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

[kasperl]

Removed Oldschool-Milestone-Later label.

[gbracha]

See issue #174. This is almost a duplicate,e xcept I am not yet convinced that a const set requires literal set syntax.

[DartBot]

This comment was originally written by @kaendfinger

---

If this were to come, I was thinking a prefix to the list literal:

const Set<String> strings = @­[
  "A",
  "B"
];

Prefixes that would maybe work would be: %, :, and ~

The @­ prefix was just a demonstration, I don't recommend that one because of annotations (metadata).

[DartBot]

This comment was originally written by @kaendfinger

---

Oops, add a const in front of the list literal in the above comment's example.

[onvlt]

I propose the curly bracket syntax for sets -- just same as maps. The only difference would be that brackes would contain particular elements instead of key-value pairs like this:

Set<String> fruits = {'apple', 'banana', orange};

Is It seems logical in many ways:

• Both map keys and set elements are uniqe. Set is like map of keys with no values.
• It corresponds with mathematical sets, which are denoted with curly braces as well.

[lacolaco]

👍

[krupalshah]

@VanNiewelt

It corresponds with mathematical sets, which are denoted with curly braces as well

. 👍

[munificent]

I propose the curly bracket syntax for sets -- just same as maps.

One problem with that is, how you define an empty set? {} is already a map. Python simply says there is no syntax for an empty set literal, but that's kind of sad.

[allumbra]

EDN (Clojure data format https://github.com/edn-format/edn) uses this syntax #{1 2 3}

It would also be cool if .add and .addAll would return a Set for better chaining

[rakudrama]

I wonder if in most cases we could infer whether {} is a Map or Set.

Side note:
@allumbra, there is no need for add and addAll to return the receiver because Dart has a built in chaining feature called cascades:

print(new Set<int>()..add(1)..add(2)..addAll([2, 3]));  // prints {1, 2, 3}

Since chaining does not 'use up' the return value, the return value can be something useful. Set.add returns true when the item was added, allowing you to write

if (items.add(item)) {
   print('Yay, a different item');
}

[lrhn]

All non-empty set literals would be distinguishable from map literals, as would any set literal with a type argument. The only tricky case is the {} literal which has no elements/entries and no type argument.
It's probably possible to infer that it's an empty Set if the surrounding context wants it to be a Set, and default to Map otherwise.
We already plan to infer the type of integer literals in a double context, and I think inferring types for ambiguous literals, or other expressions, from the context is reasonable in general, at least as long as there is always a non-ambiguous syntax that you can write instead if you want to be sure.

[natebosch]

Updated issue with links to more proposals: dart-lang/language#36

[dgrove]

Fixed in dart-lang/language#37

[bit-burger]

In swift a empty dictionary (map) literal is written as [:] to distinguish from an empty array [], in dart we could say that a empty map literal is {:} and an empty set is simply {}.

[eernstg]

An empty set is {} and an empty map is {}. When there is no information from the context about which of the two is intended, it is a map (because that's needed to ensure that existing code runs). But if you have Set<int> s = {}; the {} will be a Set<int> because of the context type for that initializing expression. This seems to work fine in practice, and we're not likely to change the syntax for an empty map at this point.

[bit-burger]

Okay, that makes sense, but will there also be a const Set() or const Set<int>() constructor for added clarity, in the cases where you need it? In the documentation it doesn't seem to be const constructor and in the dartpad it also doesn't work, maybe a const Set.empty() or const Set<int>.empty()?

[eernstg]

I don't think they will be particularly useful. If you want to document that a specific empty constant set has element type int you can use <int>{} (this can't be a Map, because they take two type arguments).

[bit-burger]

Okay, thanks for clarifying, that definitely makes sense and is also more readable than something like const Set<int>.empty(), don't know why I didn't think of that.

[eernstg]

Takes a while to think about everything. Surely we didn't. 😄