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

[Andrew Bennett]

This also works (currently):
    [1, 2] as Set

I think this is unambiguous, works with lots of things and doesn't need
to introduce new Set-specific syntax. The downside is that it's slightly
more verbose. I generally don't use Set literals often, and when I do it's
as a static let; so I don't consider the extra few characters from this
expression to be an issue.

If you can represent it concisely with an existing literal type then I
think it's worthwhile doing that, it keeps the language simple.

Andrew

On Wed, Jan 20, 2016 at 9:31 AM, Maximilian Hünenberger <
swift-evolution at swift.org> wrote:

> What about the mathematical Set notation?:
>
> let numbers = {3, 1, 4, 1, 5, 9, 2, 6, 5, 3}
>
> But this is highly ambiguous in those cases:
> let numbers = {} // closure ()->()
> let numbers = {3} // closure ()->Int
>
> So a type annotation is still needed at least for empty Sets and single
> element ones. There could be also some difficulties while parsing the swift
> file.
>
> As some others have said I'm not sure whether such additional syntax pays
> off.
>
> - Maximilian
>
> Am 19.01.2016 um 23:00 schrieb T.J. Usiyan via swift-evolution <
> swift-evolution at swift.org>:
>
> I agree that the probably isn't a better story for literals and Sets and
> that I wish that there were a better story.
>
> The best that I can think of is some sort of flag outside of the Array
> literal, for instance, #["A", "B", "C"] or just using keys that people
> aren't already accustomed to like option-'\' and option-shift-'\'.  «"A",
> "B", "C"]»
>
>
> TJ
>
> On Tue, Jan 19, 2016 at 4:55 PM, Greg Parker via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> On Jan 18, 2016, at 2:55 PM, Howard Lovatt via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> On Tuesday, 19 January 2016, Jack Lawrence <jackl at apple.com> wrote:
>>
>>
>> On Jan 18, 2016, at 2:50 PM, Liam Butler-Lawrence via swift-evolution <
>> swift-evolution at 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.
>>
>>
>> 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.
>>
>>
>> --
>> Greg Parker     gparker at apple.com     Runtime Wrangler
>>
>>
>>
>> _______________________________________________
>> 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/20160120/8ffe103b/attachment.html>