[swift-evolution] [Pitch] Named subscripts

[Adrian Zubarev]

Okay this is a view, but this design also implies multiple copies of the array, for the getter and even more for the setter, which could be expensive in some cases.

However the named subscript would allow me to mutate in-place.

Plus another side-effect of such a view design is the ability of replacing the whole storage by swapping out two similar typed views.

var string1 = "hello"
var string2 = "goodbye"

let chars1 = string1.characters
let chars2 = string2.characters

string1.characters = chars2
string2.characters = chars1
// string1 == "goodbye"
// string2 == "hello"


-- 
Adrian Zubarev
Sent with Airmail

Am 18. November 2016 um 09:19:20, Xiaodi Wu (xiaodi.wu at gmail.com) schrieb:

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/e9d6a6c7/attachment.html>