[swift-evolution] [Pitch] Named subscripts

[Xiaodi Wu]

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.scopedJ
> avaScript.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/b958b36d/attachment.html>