[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