You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: accepted/future-releases/set-literals/feature-specification.md
+19-2Lines changed: 19 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -268,6 +268,23 @@ foo({1}, {});
268
268
269
269
In any case, this needs to be finalized if/when we introduce literal spreads.
270
270
271
+
## Summary
272
+
Set literals use `{` and `}` as delimiters, allows a single type argument, and has comma-separated expressions for elements.
273
+
274
+
This syntax is distinct from map literal syntax (two type arguments, colon-pairs as elements) except for the no-type-argument empty literal `{}`.
275
+
In that case, we make it a set if the context type allows a set, and it does not allow a map, otherwise we make it a map.
276
+
277
+
Type inference works just as for list literals,
278
+
and the literal has an "exact" type (`LinkedHashSet<E>` for non-const sets,
279
+
`Set<E>` for const sets, similar to map literals).
280
+
281
+
The meaning of a set `<E>{e1, ..., en}` is a set with the same elements and iteration order as `new Set<E>()..add(e1) ... ..add(en)`.
282
+
283
+
Const set literals are allowed. Elements need to satisfy the same requirements as constant map keys (not overriding `Object.==` unless it's an integer, string or `Symbol`).
284
+
285
+
Adding set literals like this will not change any existing compilable program,
286
+
since the new syntax is either not allowed by the existing grammar, or it is rejected by the static type system.
0 commit comments