[swift-evolution] [Pitch] Named subscripts

[Dave Abrahams]

Yup 😀

Sent from my moss-covered three-handled family gradunza

> On Nov 18, 2016, at 12:18 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> I believe Dave had a design more like this in mind:
> 
> ```
> struct _View<T> {
>     let array: Array<Any>
>     subscript(index: Int) -> T? {
>         guard index >= 0 && index < array.count else { return nil }
>         return array[index] as? T
>     }
> }
> 
> extension Array {
>     var double: _View<Double> {
>         return _View(array: self)
>     }
> }
> ```
> 
>> On Fri, Nov 18, 2016 at 2:00 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
>> Hi Dave,
>> 
>> Thank you for your answer. I have to admit this is a ‘workaround’ but it will make everything even worse.
>> 
>> From:
>> 
>> public func scopedJavaScript(at index: Int) -> (javaScript: String, scope: Document)?
>> To:
>> 
>> public subscript(at index: Int) -> (javaScript: String, scope: Document)?
>> 
>> public var scopedJavaScript: Array {  
>>     get { return self }  
>>     set { /* implementation artifact */ }
>> }
>> Now I could write code like array.scopedJavaScript.scopedJavaScript.scopedJavaScript and so one, which makes no sense any more.
>> 
>> Where we could simply allow:
>> 
>> public subscript scopedJavaScript(at index: Int) -> (javaScript: String, scope: Document)?
>> This would ensure that the user can only write something like:
>> 
>> array.scopedJavaScript[at: 42] // get the value
>> array.scopedJavaScript[at: 42] = (…, …) // set the value
>> Is there anything that speaks against optionally named subscripts?
>> Technical reasons?
>> Swiftiness?
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 17. November 2016 um 23:33:44, Dave Abrahams via swift-evolution (swift-evolution at swift.org) schrieb:
>> 
>>> 
>>> on Thu Nov 17 2016, Adrian Zubarev <swift-evolution at swift.org> wrote:
>>> 
>>> > Dear Swift community,
>>> >
>>> > while building a framework for BSON I had the following idea.
>>> >
>>> > Here is a snippet of some code I do have in my module:
>>> >
>>> > extension Array where Element == Document.Value {
>>> >
>>> > public func double(at index: Int) -> Double? {
>>> >
>>> > guard self.startIndex <= index && index < self.endIndex else { return nil }
>>> >
>>> > if case .double(let double) = self[index] {
>>> >
>>> > return double
>>> > }
>>> > return nil
>>> > }
>>> >
>>> > …
>>> > }
>>> > This function is used to query the array and check if the element at the given index is of a
>>> > specific type. Now I would like also to implement a semi-schema setter.
>>> >
>>> > The problem that I see, is the ugliness of the subscript I’d create.
>>> >
>>> > Currently the code would read nicely let d = array.double(at: 42), but after change to a subscript
>>> > the API would look odd array[doubleAt: 42] = 5.0.
>>> >
>>> > Don’t get me wrong here, I also have methods with larger names like public func scopedJavaScript(at
>>> > index: Int) -> …. You can easily imagine that such subscripts would look ugly
>>> > array[scopedJavaScriptAt: 123] = ….
>>> >
>>> > I propose to align the design of subscript with functions where one could optionally give subscript
>>> > a name.
>>> >
>>> > func name(label parameter: Type) -> ReturnType
>>> >
>>> > subscript optionalName(label parameter: Type) -> ReturnType
>>> > This change would make my API nice and
>>> > clean. array.scopedJavaScript[at: 213] = …
>>> 
>>> You do that by giving your Array a scopedJavaScript property, and
>>> making that indexable.
>>> 
>>> -- 
>>> -Dave
>>> 
>>> _______________________________________________
>>> 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/20161118/9bf16fe3/attachment.html>