[Proposal] Set literal and Set type syntax

Michael_Henson · January 18, 2016, 9:24pm

Swift currently has literal and type shorthand syntax for native Array and
Dictionary types, but not the Set type. It would be useful to have a
literal shorthand for Set as well.

The existing productions for array and dictionary literals and types share
brackets as delimiters, differing only in the contents between the
brackets. That poses a slight problem for Set because any syntax, to be
useful, must also be easily distinguishable from the other types.

Consider that Arrays and Dictionaries are both naturally indexed
collections. Arrays by the integer value of the order of items in the
collection, usually implicitly, and Dictionaries by the hashed key
associated with each value.

Arrays, implicit index:

let array = ["a", "b", "c"]
var array: [String]
var empty: [String] =

Dictionaries, explicit index:

let dictionary = ["a": 1, "b": 5, "c": 9]
var dictionary: [String: Int]
var empty: [String: Int] = [:]

Sets, by contrast, have no particular order and no "key". Even though the
Set is enumerable and iterable, it isn't indexed. With that in mind, we can
declare that a Set literal or Set type literal should distinguish itself by
declaring that it has no index.

The Set literal could be:

let set = [ _: "a", "b", "c" ]
var set = [ _: String ]
var empty: [ _: String ] = [_:]

In the grammar:

set-literal -> [ _ : array-literal-items[opt] ]
literal-expression -> array-literal | dictionary-literal | set-literal

set-type -> [ _ : type ]
type -> array-type | dictionary-type | set-type | ... etc.

Examples:

let x = [ _: "A", "B", "C" ]
let y: [ _: String ] = [ _: ]

Alternatives considered:

Without literals, declaring a Set type is straightforward, easy to
recognize, and not much more verbose. There might not be enough of a
difference to justify special syntax in the core language.

Mike

sethfri · January 18, 2016, 9:47pm

I dig the idea of Sets having a literal syntax, rather than continuing to
be the ugly stepchild of CollectionTypes. I'm not sure, though, that this
particular literal syntax is very obvious. While the Array and Dictionary
syntaxes are similar enough to many other languages in which arrays and
maps exist, I might be confused if I saw your proposed syntax in Swift.

Not to mention that it's not the prettiest syntax, but that's more
subjective.

···

On Mon, Jan 18, 2016 at 1:24 PM, Michael Henson via swift-evolution < swift-evolution@swift.org> wrote:

Swift currently has literal and type shorthand syntax for native Array and
Dictionary types, but not the Set type. It would be useful to have a
literal shorthand for Set as well.

The existing productions for array and dictionary literals and types share
brackets as delimiters, differing only in the contents between the
brackets. That poses a slight problem for Set because any syntax, to be
useful, must also be easily distinguishable from the other types.

Consider that Arrays and Dictionaries are both naturally indexed
collections. Arrays by the integer value of the order of items in the
collection, usually implicitly, and Dictionaries by the hashed key
associated with each value.

Arrays, implicit index:

let array = ["a", "b", "c"]
var array: [String]
var empty: [String] =

Dictionaries, explicit index:

let dictionary = ["a": 1, "b": 5, "c": 9]
var dictionary: [String: Int]
var empty: [String: Int] = [:]

Sets, by contrast, have no particular order and no "key". Even though the
Set is enumerable and iterable, it isn't indexed. With that in mind, we can
declare that a Set literal or Set type literal should distinguish itself by
declaring that it has no index.

The Set literal could be:

let set = [ _: "a", "b", "c" ]
var set = [ _: String ]
var empty: [ _: String ] = [_:]

In the grammar:

set-literal -> [ _ : array-literal-items[opt] ]
literal-expression -> array-literal | dictionary-literal | set-literal

set-type -> [ _ : type ]
type -> array-type | dictionary-type | set-type | ... etc.

Examples:

let x = [ _: "A", "B", "C" ]
let y: [ _: String ] = [ _: ]

Alternatives considered:

Without literals, declaring a Set type is straightforward, easy to
recognize, and not much more verbose. There might not be enough of a
difference to justify special syntax in the core language.

Mike

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Seth Friedman
*Software Development Engineer II*
*Amazon.com*

jack · January 18, 2016, 10:51pm

It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and Dictionary.
Jack

···

On Jan 18, 2016, at 1:24 PM, Michael Henson via swift-evolution <swift-evolution@swift.org> wrote:

Swift currently has literal and type shorthand syntax for native Array and Dictionary types, but not the Set type. It would be useful to have a literal shorthand for Set as well.

The existing productions for array and dictionary literals and types share brackets as delimiters, differing only in the contents between the brackets. That poses a slight problem for Set because any syntax, to be useful, must also be easily distinguishable from the other types.

Consider that Arrays and Dictionaries are both naturally indexed collections. Arrays by the integer value of the order of items in the collection, usually implicitly, and Dictionaries by the hashed key associated with each value.

Arrays, implicit index:

let array = ["a", "b", "c"]
var array: [String]
var empty: [String] =

Dictionaries, explicit index:

let dictionary = ["a": 1, "b": 5, "c": 9]
var dictionary: [String: Int]
var empty: [String: Int] = [:]

Sets, by contrast, have no particular order and no "key". Even though the Set is enumerable and iterable, it isn't indexed. With that in mind, we can declare that a Set literal or Set type literal should distinguish itself by declaring that it has no index.

The Set literal could be:

let set = [ _: "a", "b", "c" ]
var set = [ _: String ]
var empty: [ _: String ] = [_:]

In the grammar:

set-literal -> [ _ : array-literal-items[opt] ]
literal-expression -> array-literal | dictionary-literal | set-literal

set-type -> [ _ : type ]
type -> array-type | dictionary-type | set-type | ... etc.

Examples:

let x = [ _: "A", "B", "C" ]
let y: [ _: String ] = [ _: ]

Alternatives considered:

Without literals, declaring a Set type is straightforward, easy to recognize, and not much more verbose. There might not be enough of a difference to justify special syntax in the core language.

Mike
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Will_Entriken · January 18, 2016, 10:12pm

Another interpretation is that a Set *is* indexed, and its value is
nonexistent. Or, in other words:

var x = [String: ()]
var y = [String: ()]()

Literals might be

var z = ["bourbon": (), "scotch": (), "beer": ()]

or more succinctly

var a = ["bourbon": (), "scotch", "beer"]

Other choices like Void or nil may be more appropriate.

···

On Mon, Jan 18, 2016 at 4:24 PM, Michael Henson via swift-evolution < swift-evolution@swift.org> wrote:

Swift currently has literal and type shorthand syntax for native Array and
Dictionary types, but not the Set type. It would be useful to have a
literal shorthand for Set as well.

The existing productions for array and dictionary literals and types share
brackets as delimiters, differing only in the contents between the
brackets. That poses a slight problem for Set because any syntax, to be
useful, must also be easily distinguishable from the other types.

Consider that Arrays and Dictionaries are both naturally indexed
collections. Arrays by the integer value of the order of items in the
collection, usually implicitly, and Dictionaries by the hashed key
associated with each value.

Arrays, implicit index:

let array = ["a", "b", "c"]
var array: [String]
var empty: [String] =

Dictionaries, explicit index:

let dictionary = ["a": 1, "b": 5, "c": 9]
var dictionary: [String: Int]
var empty: [String: Int] = [:]

Sets, by contrast, have no particular order and no "key". Even though the
Set is enumerable and iterable, it isn't indexed. With that in mind, we can
declare that a Set literal or Set type literal should distinguish itself by
declaring that it has no index.

The Set literal could be:

let set = [ _: "a", "b", "c" ]
var set = [ _: String ]
var empty: [ _: String ] = [_:]

In the grammar:

set-literal -> [ _ : array-literal-items[opt] ]
literal-expression -> array-literal | dictionary-literal | set-literal

set-type -> [ _ : type ]
type -> array-type | dictionary-type | set-type | ... etc.

Examples:

let x = [ _: "A", "B", "C" ]
let y: [ _: String ] = [ _: ]

Alternatives considered:

Without literals, declaring a Set type is straightforward, easy to
recognize, and not much more verbose. There might not be enough of a
difference to justify special syntax in the core language.

Mike

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

hlovatt · January 18, 2016, 10:43pm

Sorry -1 from me. Doesn't seem worth it. Not much wrong with Set("a", "b",
"c").

···

On Tuesday, 19 January 2016, Seth Friedman via swift-evolution < swift-evolution@swift.org> wrote:

I dig the idea of Sets having a literal syntax, rather than continuing to
be the ugly stepchild of CollectionTypes. I'm not sure, though, that this
particular literal syntax is very obvious. While the Array and Dictionary
syntaxes are similar enough to many other languages in which arrays and
maps exist, I might be confused if I saw your proposed syntax in Swift.

Not to mention that it's not the prettiest syntax, but that's more
subjective.

On Mon, Jan 18, 2016 at 1:24 PM, Michael Henson via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Swift currently has literal and type shorthand syntax for native Array
and Dictionary types, but not the Set type. It would be useful to have a
literal shorthand for Set as well.

The existing productions for array and dictionary literals and types
share brackets as delimiters, differing only in the contents between the
brackets. That poses a slight problem for Set because any syntax, to be
useful, must also be easily distinguishable from the other types.

Consider that Arrays and Dictionaries are both naturally indexed
collections. Arrays by the integer value of the order of items in the
collection, usually implicitly, and Dictionaries by the hashed key
associated with each value.

Arrays, implicit index:

let array = ["a", "b", "c"]
var array: [String]
var empty: [String] =

Dictionaries, explicit index:

let dictionary = ["a": 1, "b": 5, "c": 9]
var dictionary: [String: Int]
var empty: [String: Int] = [:]

Sets, by contrast, have no particular order and no "key". Even though the
Set is enumerable and iterable, it isn't indexed. With that in mind, we can
declare that a Set literal or Set type literal should distinguish itself by
declaring that it has no index.

The Set literal could be:

let set = [ _: "a", "b", "c" ]
var set = [ _: String ]
var empty: [ _: String ] = [_:]

In the grammar:

set-literal -> [ _ : array-literal-items[opt] ]
literal-expression -> array-literal | dictionary-literal | set-literal

set-type -> [ _ : type ]
type -> array-type | dictionary-type | set-type | ... etc.

Examples:

let x = [ _: "A", "B", "C" ]
let y: [ _: String ] = [ _: ]

Alternatives considered:

Without literals, declaring a Set type is straightforward, easy to
recognize, and not much more verbose. There might not be enough of a
difference to justify special syntax in the core language.

Mike

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Seth Friedman
*Software Development Engineer II*
*Amazon.com*

--
-- Howard.

Zhao_Xin · January 19, 2016, 1:43am

I choose let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>. The
current way. Unless the output of print(a set) change its format.

zhaoxin

···

On Tue, Jan 19, 2016 at 6:51 AM, Jack Lawrence via swift-evolution < swift-evolution@swift.org> wrote:

It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and
Dictionary.
Jack
> On Jan 18, 2016, at 1:24 PM, Michael Henson via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Swift currently has literal and type shorthand syntax for native Array
and Dictionary types, but not the Set type. It would be useful to have a
literal shorthand for Set as well.
>
> The existing productions for array and dictionary literals and types
share brackets as delimiters, differing only in the contents between the
brackets. That poses a slight problem for Set because any syntax, to be
useful, must also be easily distinguishable from the other types.
>
> Consider that Arrays and Dictionaries are both naturally indexed
collections. Arrays by the integer value of the order of items in the
collection, usually implicitly, and Dictionaries by the hashed key
associated with each value.
>
> Arrays, implicit index:
>
> let array = ["a", "b", "c"]
> var array: [String]
> var empty: [String] =
>
> Dictionaries, explicit index:
>
> let dictionary = ["a": 1, "b": 5, "c": 9]
> var dictionary: [String: Int]
> var empty: [String: Int] = [:]
>
> Sets, by contrast, have no particular order and no "key". Even though
the Set is enumerable and iterable, it isn't indexed. With that in mind, we
can declare that a Set literal or Set type literal should distinguish
itself by declaring that it has no index.
>
> The Set literal could be:
>
> let set = [ _: "a", "b", "c" ]
> var set = [ _: String ]
> var empty: [ _: String ] = [_:]
>
> In the grammar:
>
> set-literal -> [ _ : array-literal-items[opt] ]
> literal-expression -> array-literal | dictionary-literal | set-literal
>
> set-type -> [ _ : type ]
> type -> array-type | dictionary-type | set-type | ... etc.
>
>
> Examples:
>
> let x = [ _: "A", "B", "C" ]
> let y: [ _: String ] = [ _: ]
>
>
> Alternatives considered:
>
> Without literals, declaring a Set type is straightforward, easy to
recognize, and not much more verbose. There might not be enough of a
difference to justify special syntax in the core language.
>
> Mike
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Michael_Henson · January 19, 2016, 8:19pm

It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and

Dictionary

It's true that that works and is easy to understand. The two strongest
arguments I can come up with for a Set-specific syntax are:

1. The Set collection has no duplicate values, but the Array-literal
initialization syntax allows them. Disappearing values could lead to
difficult-to-diagnose problems. A Set literal type could allow the tools to
detect and notify if duplicates are given.

2. This initialization syntax is clear in this particular case, but only
because the type declaration is right there. Initializing Sets isn't as
obvious when the code is passing an argument to a function or setting the
value on structs or classes that have been declared elsewhere.

Mike

···

On Mon, Jan 18, 2016 at 2:51 PM, Jack Lawrence <jackl@apple.com> wrote:

It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and
Dictionary.
Jack
> On Jan 18, 2016, at 1:24 PM, Michael Henson via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Swift currently has literal and type shorthand syntax for native Array
and Dictionary types, but not the Set type. It would be useful to have a
literal shorthand for Set as well.
>
> The existing productions for array and dictionary literals and types
share brackets as delimiters, differing only in the contents between the
brackets. That poses a slight problem for Set because any syntax, to be
useful, must also be easily distinguishable from the other types.
>
> Consider that Arrays and Dictionaries are both naturally indexed
collections. Arrays by the integer value of the order of items in the
collection, usually implicitly, and Dictionaries by the hashed key
associated with each value.
>
> Arrays, implicit index:
>
> let array = ["a", "b", "c"]
> var array: [String]
> var empty: [String] =
>
> Dictionaries, explicit index:
>
> let dictionary = ["a": 1, "b": 5, "c": 9]
> var dictionary: [String: Int]
> var empty: [String: Int] = [:]
>
> Sets, by contrast, have no particular order and no "key". Even though
the Set is enumerable and iterable, it isn't indexed. With that in mind, we
can declare that a Set literal or Set type literal should distinguish
itself by declaring that it has no index.
>
> The Set literal could be:
>
> let set = [ _: "a", "b", "c" ]
> var set = [ _: String ]
> var empty: [ _: String ] = [_:]
>
> In the grammar:
>
> set-literal -> [ _ : array-literal-items[opt] ]
> literal-expression -> array-literal | dictionary-literal | set-literal
>
> set-type -> [ _ : type ]
> type -> array-type | dictionary-type | set-type | ... etc.
>
>
> Examples:
>
> let x = [ _: "A", "B", "C" ]
> let y: [ _: String ] = [ _: ]
>
>
> Alternatives considered:
>
> Without literals, declaring a Set type is straightforward, easy to
recognize, and not much more verbose. There might not be enough of a
difference to justify special syntax in the core language.
>
> Mike
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Tino · January 19, 2016, 4:23pm

Especially since sets are used so infrequently compared to Array and Dictionary.

I guess this is (at least partially) some kind of chicken or the egg problem:
Arrays are easy to declare, so they are often used even if you actually want set characteristics.

If you don't care for indices, and your collection should not contain duplicates, you still can use an array (and there was a time where the situation was even worse - afair Swift 1 had no native set-type).

So, I think propagating the correct use of collection types is good, but there is no natural syntax for sets, and "Set(…)" isn't that bad (I'd rather vote for removing the array-shortcut: Swift lacks the concept of fixed-size arrays, and this would be way more typing than "Set" ;-)

Tino

cryo · January 19, 2016, 6:15pm

Yes, but it still looks weird. I don’t see what’s so horrible about var a : Set = [1, 2, 3, …]. -1 from me unless a better syntax is worked out, at least.

-Sune

···

On 18 Jan 2016, at 23:12, Will Entriken via swift-evolution <swift-evolution@swift.org> wrote:

Another interpretation is that a Set *is* indexed, and its value is nonexistent. Or, in other words:

var x = [String: ()]
var y = [String: ()]()

Literals might be

var z = ["bourbon": (), "scotch": (), "beer": ()]

or more succinctly

var a = ["bourbon": (), "scotch", "beer”]

ilya · January 21, 2016, 3:43pm

Indeed, Set<T> is basically Dictionary<T, Void>
If we really need a separate syntax for sets then perhaps

var set1: [Int:]
var set2 = [2, 3, 5:]
set1= set2

will be most logical.

···

On Tue, Jan 19, 2016 at 20:12 Will Entriken via swift-evolution < swift-evolution@swift.org> wrote:

Another interpretation is that a Set *is* indexed, and its value is
nonexistent. Or, in other words:

var x = [String: ()]
var y = [String: ()]()

Literals might be

var z = ["bourbon": (), "scotch": (), "beer": ()]

or more succinctly

var a = ["bourbon": (), "scotch", "beer"]

Other choices like Void or nil may be more appropriate.

On Mon, Jan 18, 2016 at 4:24 PM, Michael Henson via swift-evolution < > swift-evolution@swift.org> wrote:

Swift currently has literal and type shorthand syntax for native Array
and Dictionary types, but not the Set type. It would be useful to have a
literal shorthand for Set as well.

The existing productions for array and dictionary literals and types
share brackets as delimiters, differing only in the contents between the
brackets. That poses a slight problem for Set because any syntax, to be
useful, must also be easily distinguishable from the other types.

Consider that Arrays and Dictionaries are both naturally indexed
collections. Arrays by the integer value of the order of items in the
collection, usually implicitly, and Dictionaries by the hashed key
associated with each value.

Arrays, implicit index:

let array = ["a", "b", "c"]
var array: [String]
var empty: [String] =

Dictionaries, explicit index:

let dictionary = ["a": 1, "b": 5, "c": 9]
var dictionary: [String: Int]
var empty: [String: Int] = [:]

Sets, by contrast, have no particular order and no "key". Even though the
Set is enumerable and iterable, it isn't indexed. With that in mind, we can
declare that a Set literal or Set type literal should distinguish itself by
declaring that it has no index.

The Set literal could be:

let set = [ _: "a", "b", "c" ]
var set = [ _: String ]
var empty: [ _: String ] = [_:]

In the grammar:

set-literal -> [ _ : array-literal-items[opt] ]
literal-expression -> array-literal | dictionary-literal | set-literal

set-type -> [ _ : type ]
type -> array-type | dictionary-type | set-type | ... etc.

Examples:

let x = [ _: "A", "B", "C" ]
let y: [ _: String ] = [ _: ]

Alternatives considered:

Without literals, declaring a Set type is straightforward, easy to
recognize, and not much more verbose. There might not be enough of a
difference to justify special syntax in the core language.

Mike

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

jack · January 18, 2016, 10:53pm

init(arrayLiteral:) is there to satisfy ArrayLiteralConvertible. Set([“a”, “b”, “c”]) works just fine.

Jack

···

On Jan 18, 2016, at 2:50 PM, Liam Butler-Lawrence via swift-evolution <swift-evolution@swift.org> wrote:

Set("a", "b", "c”) doesn’t compile. It currently has to be Set(arrayLiteral: "a", "b", "c”). That said, I’d be satisfied with removing the external parameter name “arrayLiteral”. Not only is it unnecessary, but it’s confusing too: variadic parameters are not the same as an Array.

Liam

On Jan 18, 2016, at 5:43 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Sorry -1 from me. Doesn't seem worth it. Not much wrong with Set("a", "b", "c").

On Tuesday, 19 January 2016, Seth Friedman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I dig the idea of Sets having a literal syntax, rather than continuing to be the ugly stepchild of CollectionTypes. I'm not sure, though, that this particular literal syntax is very obvious. While the Array and Dictionary syntaxes are similar enough to many other languages in which arrays and maps exist, I might be confused if I saw your proposed syntax in Swift.

Not to mention that it's not the prettiest syntax, but that's more subjective.

On Mon, Jan 18, 2016 at 1:24 PM, Michael Henson via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:
Swift currently has literal and type shorthand syntax for native Array and Dictionary types, but not the Set type. It would be useful to have a literal shorthand for Set as well.

The existing productions for array and dictionary literals and types share brackets as delimiters, differing only in the contents between the brackets. That poses a slight problem for Set because any syntax, to be useful, must also be easily distinguishable from the other types.

Consider that Arrays and Dictionaries are both naturally indexed collections. Arrays by the integer value of the order of items in the collection, usually implicitly, and Dictionaries by the hashed key associated with each value.

Arrays, implicit index:

let array = ["a", "b", "c"]
var array: [String]
var empty: [String] =

Dictionaries, explicit index:

let dictionary = ["a": 1, "b": 5, "c": 9]
var dictionary: [String: Int]
var empty: [String: Int] = [:]

Sets, by contrast, have no particular order and no "key". Even though the Set is enumerable and iterable, it isn't indexed. With that in mind, we can declare that a Set literal or Set type literal should distinguish itself by declaring that it has no index.

The Set literal could be:

let set = [ _: "a", "b", "c" ]
var set = [ _: String ]
var empty: [ _: String ] = [_:]

In the grammar:

set-literal -> [ _ : array-literal-items[opt] ]
literal-expression -> array-literal | dictionary-literal | set-literal

set-type -> [ _ : type ]
type -> array-type | dictionary-type | set-type | ... etc.

Examples:

let x = [ _: "A", "B", "C" ]
let y: [ _: String ] = [ _: ]

Alternatives considered:

Without literals, declaring a Set type is straightforward, easy to recognize, and not much more verbose. There might not be enough of a difference to justify special syntax in the core language.

Mike

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Seth Friedman
Software Development Engineer II
Amazon.com <http://amazon.com/>

--
-- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Liam_Butler-Lawrence · January 18, 2016, 10:50pm

Set("a", "b", "c”) doesn’t compile. It currently has to be Set(arrayLiteral: "a", "b", "c”). That said, I’d be satisfied with removing the external parameter name “arrayLiteral”. Not only is it unnecessary, but it’s confusing too: variadic parameters are not the same as an Array.

Liam

···

On Jan 18, 2016, at 5:43 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:

Sorry -1 from me. Doesn't seem worth it. Not much wrong with Set("a", "b", "c").

On Tuesday, 19 January 2016, Seth Friedman via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I dig the idea of Sets having a literal syntax, rather than continuing to be the ugly stepchild of CollectionTypes. I'm not sure, though, that this particular literal syntax is very obvious. While the Array and Dictionary syntaxes are similar enough to many other languages in which arrays and maps exist, I might be confused if I saw your proposed syntax in Swift.

Not to mention that it's not the prettiest syntax, but that's more subjective.

On Mon, Jan 18, 2016 at 1:24 PM, Michael Henson via swift-evolution <swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:
Swift currently has literal and type shorthand syntax for native Array and Dictionary types, but not the Set type. It would be useful to have a literal shorthand for Set as well.

The existing productions for array and dictionary literals and types share brackets as delimiters, differing only in the contents between the brackets. That poses a slight problem for Set because any syntax, to be useful, must also be easily distinguishable from the other types.

Consider that Arrays and Dictionaries are both naturally indexed collections. Arrays by the integer value of the order of items in the collection, usually implicitly, and Dictionaries by the hashed key associated with each value.

Arrays, implicit index:

let array = ["a", "b", "c"]
var array: [String]
var empty: [String] =

Dictionaries, explicit index:

let dictionary = ["a": 1, "b": 5, "c": 9]
var dictionary: [String: Int]
var empty: [String: Int] = [:]

Sets, by contrast, have no particular order and no "key". Even though the Set is enumerable and iterable, it isn't indexed. With that in mind, we can declare that a Set literal or Set type literal should distinguish itself by declaring that it has no index.

The Set literal could be:

let set = [ _: "a", "b", "c" ]
var set = [ _: String ]
var empty: [ _: String ] = [_:]

In the grammar:

set-literal -> [ _ : array-literal-items[opt] ]
literal-expression -> array-literal | dictionary-literal | set-literal

set-type -> [ _ : type ]
type -> array-type | dictionary-type | set-type | ... etc.

Examples:

let x = [ _: "A", "B", "C" ]
let y: [ _: String ] = [ _: ]

Alternatives considered:

Without literals, declaring a Set type is straightforward, easy to recognize, and not much more verbose. There might not be enough of a difference to justify special syntax in the core language.

Mike

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Seth Friedman
Software Development Engineer II
Amazon.com

--
-- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Haravikk1 · January 19, 2016, 9:18am

Same here, as you long as you specify Set as a type then the standard array syntax works just fine, the only case in which it doesn’t work is when you want to do something like:

[1,2,3,4].someMethod()

But that isn’t usually a great way to use array/set constants anyway so I don’t think it’s a big deal.

A more interesting question IMO is whether we could extend the array syntax to apply to any sequence type, for example:

let mySequence:SomeProtocol = [1, 2, 3, 4]

i.e- could we add a protocol that Array and Set conform to in order to support that style of initialisation, that we could also apply to other types as well. Is that worth its own proposal?

···

On 19 Jan 2016, at 01:43, zhaoxin肇鑫 via swift-evolution <swift-evolution@swift.org> wrote:

I choose let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>. The current way. Unless the output of print(a set) change its format.

zhaoxin

On Tue, Jan 19, 2016 at 6:51 AM, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and Dictionary.
Jack
> On Jan 18, 2016, at 1:24 PM, Michael Henson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Swift currently has literal and type shorthand syntax for native Array and Dictionary types, but not the Set type. It would be useful to have a literal shorthand for Set as well.
>
> The existing productions for array and dictionary literals and types share brackets as delimiters, differing only in the contents between the brackets. That poses a slight problem for Set because any syntax, to be useful, must also be easily distinguishable from the other types.
>
> Consider that Arrays and Dictionaries are both naturally indexed collections. Arrays by the integer value of the order of items in the collection, usually implicitly, and Dictionaries by the hashed key associated with each value.
>
> Arrays, implicit index:
>
> let array = ["a", "b", "c"]
> var array: [String]
> var empty: [String] =
>
> Dictionaries, explicit index:
>
> let dictionary = ["a": 1, "b": 5, "c": 9]
> var dictionary: [String: Int]
> var empty: [String: Int] = [:]
>
> Sets, by contrast, have no particular order and no "key". Even though the Set is enumerable and iterable, it isn't indexed. With that in mind, we can declare that a Set literal or Set type literal should distinguish itself by declaring that it has no index.
>
> The Set literal could be:
>
> let set = [ _: "a", "b", "c" ]
> var set = [ _: String ]
> var empty: [ _: String ] = [_:]
>
> In the grammar:
>
> set-literal -> [ _ : array-literal-items[opt] ]
> literal-expression -> array-literal | dictionary-literal | set-literal
>
> set-type -> [ _ : type ]
> type -> array-type | dictionary-type | set-type | ... etc.
>
>
> Examples:
>
> let x = [ _: "A", "B", "C" ]
> let y: [ _: String ] = [ _: ]
>
>
> Alternatives considered:
>
> Without literals, declaring a Set type is straightforward, easy to recognize, and not much more verbose. There might not be enough of a difference to justify special syntax in the core language.
>
> Mike
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

hlovatt · January 18, 2016, 10:53pm

Thanks for the correction and I agree that removing the argument label
would be a good idea.

···

On Tuesday, 19 January 2016, Liam Butler-Lawrence <liamdunn@me.com> wrote:

Set("a", "b", "c”) doesn’t compile. It currently has to be Set(arrayLiteral:
"a", "b", "c”). That said, I’d be satisfied with removing the external
parameter name “arrayLiteral”. Not only is it unnecessary, but it’s
confusing too: variadic parameters are not the same as an Array.

Liam

On Jan 18, 2016, at 5:43 PM, Howard Lovatt via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Sorry -1 from me. Doesn't seem worth it. Not much wrong with Set("a", "b",
"c").

On Tuesday, 19 January 2016, Seth Friedman via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

I dig the idea of Sets having a literal syntax, rather than continuing to
be the ugly stepchild of CollectionTypes. I'm not sure, though, that this
particular literal syntax is very obvious. While the Array and Dictionary
syntaxes are similar enough to many other languages in which arrays and
maps exist, I might be confused if I saw your proposed syntax in Swift.

Not to mention that it's not the prettiest syntax, but that's more
subjective.

On Mon, Jan 18, 2016 at 1:24 PM, Michael Henson via swift-evolution < >> swift-evolution@swift.org> wrote:

Swift currently has literal and type shorthand syntax for native Array
and Dictionary types, but not the Set type. It would be useful to have a
literal shorthand for Set as well.

The existing productions for array and dictionary literals and types
share brackets as delimiters, differing only in the contents between the
brackets. That poses a slight problem for Set because any syntax, to be
useful, must also be easily distinguishable from the other types.

Consider that Arrays and Dictionaries are both naturally indexed
collections. Arrays by the integer value of the order of items in the
collection, usually implicitly, and Dictionaries by the hashed key
associated with each value.

Arrays, implicit index:

let array = ["a", "b", "c"]
var array: [String]
var empty: [String] =

Dictionaries, explicit index:

let dictionary = ["a": 1, "b": 5, "c": 9]
var dictionary: [String: Int]
var empty: [String: Int] = [:]

Sets, by contrast, have no particular order and no "key". Even though
the Set is enumerable and iterable, it isn't indexed. With that in mind, we
can declare that a Set literal or Set type literal should distinguish
itself by declaring that it has no index.

The Set literal could be:

let set = [ _: "a", "b", "c" ]
var set = [ _: String ]
var empty: [ _: String ] = [_:]

In the grammar:

set-literal -> [ _ : array-literal-items[opt] ]
literal-expression -> array-literal | dictionary-literal | set-literal

set-type -> [ _ : type ]
type -> array-type | dictionary-type | set-type | ... etc.

Examples:

let x = [ _: "A", "B", "C" ]
let y: [ _: String ] = [ _: ]

Alternatives considered:

Without literals, declaring a Set type is straightforward, easy to
recognize, and not much more verbose. There might not be enough of a
difference to justify special syntax in the core language.

Mike

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Seth Friedman
*Software Development Engineer II*
*Amazon.com <http://amazon.com>*

--
-- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

hlovatt · January 18, 2016, 10:55pm

Sure, but you could add another overload without the label.

···

On Tuesday, 19 January 2016, Jack Lawrence <jackl@apple.com> wrote:

init(arrayLiteral:) is there to satisfy ArrayLiteralConvertible. Set([“a”,
“b”, “c”]) works just fine.

Jack

On Jan 18, 2016, at 2:50 PM, Liam Butler-Lawrence via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Set("a", "b", "c”) doesn’t compile. It currently has to be Set(arrayLiteral:
"a", "b", "c”). That said, I’d be satisfied with removing the external
parameter name “arrayLiteral”. Not only is it unnecessary, but it’s
confusing too: variadic parameters are not the same as an Array.

Liam

On Jan 18, 2016, at 5:43 PM, Howard Lovatt via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Sorry -1 from me. Doesn't seem worth it. Not much wrong with Set("a", "b",
"c").

On Tuesday, 19 January 2016, Seth Friedman via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

I dig the idea of Sets having a literal syntax, rather than continuing to
be the ugly stepchild of CollectionTypes. I'm not sure, though, that this
particular literal syntax is very obvious. While the Array and Dictionary
syntaxes are similar enough to many other languages in which arrays and
maps exist, I might be confused if I saw your proposed syntax in Swift.

Not to mention that it's not the prettiest syntax, but that's more
subjective.

On Mon, Jan 18, 2016 at 1:24 PM, Michael Henson via swift-evolution < >> swift-evolution@swift.org> wrote:

Swift currently has literal and type shorthand syntax for native Array
and Dictionary types, but not the Set type. It would be useful to have a
literal shorthand for Set as well.

The existing productions for array and dictionary literals and types
share brackets as delimiters, differing only in the contents between the
brackets. That poses a slight problem for Set because any syntax, to be
useful, must also be easily distinguishable from the other types.

Consider that Arrays and Dictionaries are both naturally indexed
collections. Arrays by the integer value of the order of items in the
collection, usually implicitly, and Dictionaries by the hashed key
associated with each value.

Arrays, implicit index:

let array = ["a", "b", "c"]
var array: [String]
var empty: [String] =

Dictionaries, explicit index:

let dictionary = ["a": 1, "b": 5, "c": 9]
var dictionary: [String: Int]
var empty: [String: Int] = [:]

Sets, by contrast, have no particular order and no "key". Even though
the Set is enumerable and iterable, it isn't indexed. With that in mind, we
can declare that a Set literal or Set type literal should distinguish
itself by declaring that it has no index.

The Set literal could be:

let set = [ _: "a", "b", "c" ]
var set = [ _: String ]
var empty: [ _: String ] = [_:]

In the grammar:

set-literal -> [ _ : array-literal-items[opt] ]
literal-expression -> array-literal | dictionary-literal | set-literal

set-type -> [ _ : type ]
type -> array-type | dictionary-type | set-type | ... etc.

Examples:

let x = [ _: "A", "B", "C" ]
let y: [ _: String ] = [ _: ]

Alternatives considered:

Without literals, declaring a Set type is straightforward, easy to
recognize, and not much more verbose. There might not be enough of a
difference to justify special syntax in the core language.

Mike

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Seth Friedman
*Software Development Engineer II*
*Amazon.com <http://amazon.com/>\*

--
-- Howard.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

johankj · January 19, 2016, 10:35am

Isn't that exactly what ArrayLiteralConvertible does?

extension CustomType: ArrayLiteralConvertible {
typealias Element = Int
init(arrayLiteral elements: Element...) {

}
}

let c: CustomType = [1,2,3,4]

···

On Tue, Jan 19, 2016 at 10:18 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote:

Same here, as you long as you specify Set as a type then the standard
array syntax works just fine, the only case in which it doesn’t work is
when you want to do something like:

[1,2,3,4].someMethod()

But that isn’t usually a great way to use array/set constants anyway so I
don’t think it’s a big deal.

A more interesting question IMO is whether we could extend the array
syntax to apply to any sequence type, for example:

let mySequence:SomeProtocol = [1, 2, 3, 4]

i.e- could we add a protocol that Array and Set conform to in order to
support that style of initialisation, that we could also apply to other
types as well. Is that worth its own proposal?

On 19 Jan 2016, at 01:43, zhaoxin肇鑫 via swift-evolution < > swift-evolution@swift.org> wrote:

I choose let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>. The
current way. Unless the output of print(a set) change its format.

zhaoxin

On Tue, Jan 19, 2016 at 6:51 AM, Jack Lawrence via swift-evolution < > swift-evolution@swift.org> wrote:

It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and
Dictionary.
Jack
> On Jan 18, 2016, at 1:24 PM, Michael Henson via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> Swift currently has literal and type shorthand syntax for native Array
and Dictionary types, but not the Set type. It would be useful to have a
literal shorthand for Set as well.
>
> The existing productions for array and dictionary literals and types
share brackets as delimiters, differing only in the contents between the
brackets. That poses a slight problem for Set because any syntax, to be
useful, must also be easily distinguishable from the other types.
>
> Consider that Arrays and Dictionaries are both naturally indexed
collections. Arrays by the integer value of the order of items in the
collection, usually implicitly, and Dictionaries by the hashed key
associated with each value.
>
> Arrays, implicit index:
>
> let array = ["a", "b", "c"]
> var array: [String]
> var empty: [String] =
>
> Dictionaries, explicit index:
>
> let dictionary = ["a": 1, "b": 5, "c": 9]
> var dictionary: [String: Int]
> var empty: [String: Int] = [:]
>
> Sets, by contrast, have no particular order and no "key". Even though
the Set is enumerable and iterable, it isn't indexed. With that in mind, we
can declare that a Set literal or Set type literal should distinguish
itself by declaring that it has no index.
>
> The Set literal could be:
>
> let set = [ _: "a", "b", "c" ]
> var set = [ _: String ]
> var empty: [ _: String ] = [_:]
>
> In the grammar:
>
> set-literal -> [ _ : array-literal-items[opt] ]
> literal-expression -> array-literal | dictionary-literal | set-literal
>
> set-type -> [ _ : type ]
> type -> array-type | dictionary-type | set-type | ... etc.
>
>
> Examples:
>
> let x = [ _: "A", "B", "C" ]
> let y: [ _: String ] = [ _: ]
>
>
> Alternatives considered:
>
> Without literals, declaring a Set type is straightforward, easy to
recognize, and not much more verbose. There might not be enough of a
difference to justify special syntax in the core language.
>
> Mike
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

salutis · January 21, 2016, 10:09am

This is a great point. The compiler should emit a warning in case of duplicate values:

let numbers: Set<Int> = [0, 0]

R+

···

Sent from my iPhone

On 19 Jan 2016, at 21:19, Michael Henson via swift-evolution <swift-evolution@swift.org> wrote:

It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and Dictionary

It's true that that works and is easy to understand. The two strongest arguments I can come up with for a Set-specific syntax are:

1. The Set collection has no duplicate values, but the Array-literal initialization syntax allows them. Disappearing values could lead to difficult-to-diagnose problems. A Set literal type could allow the tools to detect and notify if duplicates are given.

2. This initialization syntax is clear in this particular case, but only because the type declaration is right there. Initializing Sets isn't as obvious when the code is passing an argument to a function or setting the value on structs or classes that have been declared elsewhere.

Mike

On Mon, Jan 18, 2016 at 2:51 PM, Jack Lawrence <jackl@apple.com> wrote:
It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and Dictionary.
Jack
> On Jan 18, 2016, at 1:24 PM, Michael Henson via swift-evolution <swift-evolution@swift.org> wrote:
>
> Swift currently has literal and type shorthand syntax for native Array and Dictionary types, but not the Set type. It would be useful to have a literal shorthand for Set as well.
>
> The existing productions for array and dictionary literals and types share brackets as delimiters, differing only in the contents between the brackets. That poses a slight problem for Set because any syntax, to be useful, must also be easily distinguishable from the other types.
>
> Consider that Arrays and Dictionaries are both naturally indexed collections. Arrays by the integer value of the order of items in the collection, usually implicitly, and Dictionaries by the hashed key associated with each value.
>
> Arrays, implicit index:
>
> let array = ["a", "b", "c"]
> var array: [String]
> var empty: [String] =
>
> Dictionaries, explicit index:
>
> let dictionary = ["a": 1, "b": 5, "c": 9]
> var dictionary: [String: Int]
> var empty: [String: Int] = [:]
>
> Sets, by contrast, have no particular order and no "key". Even though the Set is enumerable and iterable, it isn't indexed. With that in mind, we can declare that a Set literal or Set type literal should distinguish itself by declaring that it has no index.
>
> The Set literal could be:
>
> let set = [ _: "a", "b", "c" ]
> var set = [ _: String ]
> var empty: [ _: String ] = [_:]
>
> In the grammar:
>
> set-literal -> [ _ : array-literal-items[opt] ]
> literal-expression -> array-literal | dictionary-literal | set-literal
>
> set-type -> [ _ : type ]
> type -> array-type | dictionary-type | set-type | ... etc.
>
>
> Examples:
>
> let x = [ _: "A", "B", "C" ]
> let y: [ _: String ] = [ _: ]
>
>
> Alternatives considered:
>
> Without literals, declaring a Set type is straightforward, easy to recognize, and not much more verbose. There might not be enough of a difference to justify special syntax in the core language.
>
> Mike
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Haravikk2 · January 19, 2016, 12:08pm

Yes indeed, in that case please disregard that comment, I drew a mental blank for some reason!

Thinking about it I’m just not sure about a syntax specifically for sets. That said, I’m kind of interested by the idea of the proposed syntax in terms of being able to specify a type of index for any indexed type (with underscore indicating no index as proposed). For example:

let x:SomeIndexedType = [Int:1, 2, 3, 4] // An indexed collection where the index type is Int (e.g- a regular Array)
let x:SomeIndexedType = [UInt8: 1, 2, 3, 4] // Similar to above, but limited to Uint8 indexes the type is incapable of storing more than 256 elements, coincidentally if you convert your indices from a larger integer type by truncating then you get automatic round-robin storage.
let x = [_: 1, 2, 3, 4] // Set as a special case (otherwise indexed types would need to handle optional index types)

Given that the collection types are already written to use the index paradigm externally rather than just assuming the use of Int for indices, this could allow for some interesting possibilities from using custom index types, e.g- allowing an Array to store elements by alphabetic letters. Of course internally some changes might be needed as collections would need to use the distance from the start index to perform lookups, but for integer types this should optimise away I think, and shouldn't be a difficult change to make.

But yeah; for Sets only I’m not convinced the need is worth it given that array syntax works in most cases, but if the same syntax can be useful for a broader range of types it could be interesting.

···

On 19 Jan 2016, at 10:35, Johan Jensen via swift-evolution <swift-evolution@swift.org> wrote:

Isn't that exactly what ArrayLiteralConvertible does?

extension CustomType: ArrayLiteralConvertible {
    typealias Element = Int
    init(arrayLiteral elements: Element...) {

    }
}

let c: CustomType = [1,2,3,4]

On Tue, Jan 19, 2016 at 10:18 AM, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Same here, as you long as you specify Set as a type then the standard array syntax works just fine, the only case in which it doesn’t work is when you want to do something like:

[1,2,3,4].someMethod()

But that isn’t usually a great way to use array/set constants anyway so I don’t think it’s a big deal.

A more interesting question IMO is whether we could extend the array syntax to apply to any sequence type, for example:

let mySequence:SomeProtocol = [1, 2, 3, 4]

i.e- could we add a protocol that Array and Set conform to in order to support that style of initialisation, that we could also apply to other types as well. Is that worth its own proposal?

On 19 Jan 2016, at 01:43, zhaoxin肇鑫 via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I choose let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>. The current way. Unless the output of print(a set) change its format.

zhaoxin

On Tue, Jan 19, 2016 at 6:51 AM, Jack Lawrence via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and Dictionary.
Jack
> On Jan 18, 2016, at 1:24 PM, Michael Henson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Swift currently has literal and type shorthand syntax for native Array and Dictionary types, but not the Set type. It would be useful to have a literal shorthand for Set as well.
>
> The existing productions for array and dictionary literals and types share brackets as delimiters, differing only in the contents between the brackets. That poses a slight problem for Set because any syntax, to be useful, must also be easily distinguishable from the other types.
>
> Consider that Arrays and Dictionaries are both naturally indexed collections. Arrays by the integer value of the order of items in the collection, usually implicitly, and Dictionaries by the hashed key associated with each value.
>
> Arrays, implicit index:
>
> let array = ["a", "b", "c"]
> var array: [String]
> var empty: [String] =
>
> Dictionaries, explicit index:
>
> let dictionary = ["a": 1, "b": 5, "c": 9]
> var dictionary: [String: Int]
> var empty: [String: Int] = [:]
>
> Sets, by contrast, have no particular order and no "key". Even though the Set is enumerable and iterable, it isn't indexed. With that in mind, we can declare that a Set literal or Set type literal should distinguish itself by declaring that it has no index.
>
> The Set literal could be:
>
> let set = [ _: "a", "b", "c" ]
> var set = [ _: String ]
> var empty: [ _: String ] = [_:]
>
> In the grammar:
>
> set-literal -> [ _ : array-literal-items[opt] ]
> literal-expression -> array-literal | dictionary-literal | set-literal
>
> set-type -> [ _ : type ]
> type -> array-type | dictionary-type | set-type | ... etc.
>
>
> Examples:
>
> let x = [ _: "A", "B", "C" ]
> let y: [ _: String ] = [ _: ]
>
>
> Alternatives considered:
>
> Without literals, declaring a Set type is straightforward, easy to recognize, and not much more verbose. There might not be enough of a difference to justify special syntax in the core language.
>
> Mike
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

gparker42 · January 19, 2016, 9:55pm

Only if you break existing code. Consider this expression:

Set(["a", "b"])

Is this
1. a Set<String> with two elements "a" and "b"
2. a Set<Array<String>> with one element ["a", "b"]

Currently it means #1. You could change it to mean #2, but that breaks existing code that expects #1. You could try to overload the no-name initializer, but that will be confusing to humans in some cases.

···

On Jan 18, 2016, at 2:55 PM, Howard Lovatt via swift-evolution <swift-evolution@swift.org> wrote:

On Tuesday, 19 January 2016, Jack Lawrence <jackl@apple.com <mailto:jackl@apple.com>> wrote:

On Jan 18, 2016, at 2:50 PM, Liam Butler-Lawrence via swift-evolution <swift-evolution@swift.org> wrote:

Set("a", "b", "c”) doesn’t compile. It currently has to be Set(arrayLiteral: "a", "b", "c”). That said, I’d be satisfied with removing the external parameter name “arrayLiteral”. Not only is it unnecessary, but it’s confusing too: variadic parameters are not the same as an Array.

init(arrayLiteral:) is there to satisfy ArrayLiteralConvertible. Set([“a”, “b”, “c”]) works just fine.

Sure, but you could add another overload without the label.

--
Greg Parker gparker@apple.com Runtime Wrangler

Austin · January 21, 2016, 10:12am

I agree that this is a desirable property, but it would only work for literals. In the most general sense, `Hashable` instances are only guaranteed to be comparable for equality at runtime.

Austin

···

On Jan 21, 2016, at 2:09 AM, Rudolf Adamkovic via swift-evolution <swift-evolution@swift.org> wrote:

This is a great point. The compiler should emit a warning in case of duplicate values:

let numbers: Set<Int> = [0, 0]

R+

Sent from my iPhone

On 19 Jan 2016, at 21:19, Michael Henson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and Dictionary

It's true that that works and is easy to understand. The two strongest arguments I can come up with for a Set-specific syntax are:

1. The Set collection has no duplicate values, but the Array-literal initialization syntax allows them. Disappearing values could lead to difficult-to-diagnose problems. A Set literal type could allow the tools to detect and notify if duplicates are given.

2. This initialization syntax is clear in this particular case, but only because the type declaration is right there. Initializing Sets isn't as obvious when the code is passing an argument to a function or setting the value on structs or classes that have been declared elsewhere.

Mike

On Mon, Jan 18, 2016 at 2:51 PM, Jack Lawrence <jackl@apple.com <mailto:jackl@apple.com>> wrote:
It doesn’t seem like a big enough win over:

let x: Set = [1, 2, 3, 4] // x inferred to be Set<Int>

Especially since sets are used so infrequently compared to Array and Dictionary.
Jack
> On Jan 18, 2016, at 1:24 PM, Michael Henson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Swift currently has literal and type shorthand syntax for native Array and Dictionary types, but not the Set type. It would be useful to have a literal shorthand for Set as well.
>
> The existing productions for array and dictionary literals and types share brackets as delimiters, differing only in the contents between the brackets. That poses a slight problem for Set because any syntax, to be useful, must also be easily distinguishable from the other types.
>
> Consider that Arrays and Dictionaries are both naturally indexed collections. Arrays by the integer value of the order of items in the collection, usually implicitly, and Dictionaries by the hashed key associated with each value.
>
> Arrays, implicit index:
>
> let array = ["a", "b", "c"]
> var array: [String]
> var empty: [String] =
>
> Dictionaries, explicit index:
>
> let dictionary = ["a": 1, "b": 5, "c": 9]
> var dictionary: [String: Int]
> var empty: [String: Int] = [:]
>
> Sets, by contrast, have no particular order and no "key". Even though the Set is enumerable and iterable, it isn't indexed. With that in mind, we can declare that a Set literal or Set type literal should distinguish itself by declaring that it has no index.
>
> The Set literal could be:
>
> let set = [ _: "a", "b", "c" ]
> var set = [ _: String ]
> var empty: [ _: String ] = [_:]
>
> In the grammar:
>
> set-literal -> [ _ : array-literal-items[opt] ]
> literal-expression -> array-literal | dictionary-literal | set-literal
>
> set-type -> [ _ : type ]
> type -> array-type | dictionary-type | set-type | ... etc.
>
>
> Examples:
>
> let x = [ _: "A", "B", "C" ]
> let y: [ _: String ] = [ _: ]
>
>
> Alternatives considered:
>
> Without literals, declaring a Set type is straightforward, easy to recognize, and not much more verbose. There might not be enough of a difference to justify special syntax in the core language.
>
> Mike
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution