[swift-evolution] Change subscripts to use colons
James Froggatt
james.froggatt at me.com
Mon Jul 11 14:44:36 CDT 2016
This is an interesting idea, but probably deserves its own proposal.
Personally, I like the reuse of parameter list syntax, and think that, if anything, subscripts should be updated at the call-site to use round brackets. There shouldn't be any ambiguity problems, though readability could drop substantially… Probably not a good idea.
> On 11 Jul 2016, at 20:38, Sean Heber <sean at fifthace.com> wrote:
>
> The only thing that really bugs me about subscript is that you declare it with (), but use it with []. I’ve never found the return indicator to be confusing here. I get the argument in favor of property-ness, though.
>
> Wouldn’t mind considering using square brackets instead, but perhaps that has already been tried and rejected at some point:
>
> subscript[_ position: Int] -> {}
>
> l8r
> Sean
>
>
>> On Jul 11, 2016, at 2:32 PM, James Froggatt via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> Interesting way to think of the ‘->’ operator.
>>
>> Perhaps a <-> operator could represent this two-way mapping?
>>
>>> On 11 Jul 2016, at 20:29, Erica Sadun <erica at ericasadun.com> wrote:
>>>
>>> On Jul 11, 2016, at 1:21 PM, James Froggatt via swift-evolution <swift-evolution at swift.org> wrote:
>>>>
>>>> Thanks for letting me know this has been tried before, I'm actually in the process of drafting the proposal now.
>>>
>>> I'd hesitate to try to do something off-beat and "blend" them but it amuses me no end that the :-> operator looks so very happy.
>>>
>>> subscript(_ position: Int) inout :-> Element { get { … } set { … } }
>>>
>>> Nonetheless, I do want to point out that unlike properties, subscripts provide a mapping between a domain and a range so it feels more natural to me to use -> than :.
>>>
>>> -- E
>>>
>>>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
More information about the swift-evolution
mailing list