[swift-evolution] [Proposal] Set literal and Set type syntax

[Johan Jensen]

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 at 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 at 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 at 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 at 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 at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160119/f9329623/attachment.html>