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 ([email protected]) 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 <[email protected]> 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 ([email protected]) schrieb: on Thu Nov 17 2016, Adrian Zubarev <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
