Yup 😀 Sent from my moss-covered three-handled family gradunza
> On Nov 18, 2016, at 12:18 AM, Xiaodi Wu <[email protected]> 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 >> <[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
