> > I investigated tuples a bit, it's close. The one thing I'd need is being > > able to index the values using a variable. The tuple.i notation apparently > > doesn't work (or I did not try hard enough). Also, for low-level things > > that will be mapped to GPU memory, precise/predictable/settable alignment > > is needed.
This might be a bit hacky but I just wanted to point out there exists a way to index into tuples. You can use the Mirror(reflecting: tuple).children syntax. You can loop over the values of the tuple and even though a bit awkward you can even use indices to index into the children. Regards, Manav Gabhawala On August 4, 2016 at 5:18:13 AM, James Froggatt via swift-evolution ([email protected](mailto:[email protected])) wrote: > > > On 4 Aug 2016, at 13:00, Raphael Sebbe wrote: > > > Thank you Chris, James. > > > > I'm answering James feedback/questions below. > > > > On Thu, Aug 4, 2016 at 1:57 AM James Froggatt wrote: > > > > > What are your thoughts on using tuples for this? > > > > > > typealias CGPoint4 = (CGPoint, CGPoint, CGPoint, CGPoint) > > > > > > struct Quad { var corners: CGPoint4 } > > > > > > var fixedLength = (point1, point2, point3, point4) > > > print(fixedLength.0) > > > print(fixedLength.4) //compiler error, not an element of the tuple > > > > > > > > > With shorthand declaration syntax, this would have the benefits of a > > > fixed-length array with added compile-time safety. A previously suggested > > > syntax was along the lines of '(CGPoint * 4)'. > > > > > > > I investigated tuples a bit, it's close. The one thing I'd need is being > > able to index the values using a variable. The tuple.i notation apparently > > doesn't work (or I did not try hard enough). Also, for low-level things > > that will be mapped to GPU memory, precise/predictable/settable alignment > > is needed. > > Good point. A similar mechanism might be possible eventually for tuples, but > right now this isn't possible. > > > > 4. Reference/pointer to structs: accessing & modifying structs deep > > > > into the model currently requires fully qualified path to the struct > > > > instance. Fully qualifying an inner struct in your data model can be > > > > very tedious, depending on model complexity. > > > > > > > > For instance, with scoped access solutions made with Swift 3, you need > > > > to cascade blocks if you need to access multiple inner structs, which > > > > doesn't scale well as it creates code pyramids: > > > > > > > > scopedAccess(&varA) { > > > > scopedAccess(&varB) { > > > > // modify varA & varB > > > > } > > > > } > > > > > > > > It's easily done in C/C++ using pointers/references. To make that > > > > better, we'd need some kind of language support IMO. > > > > > > > > > > > > > > > > > Could this be generalised, maybe with a reference-semantic ‘property > > > accessor’? > > > > > > Example: > > > > > > let get: () -> Bool = #get(controller.view.isVisible) > > > print(get()) > > > > > > let set: (Bool) -> () = #set(controller.view.isVisible) > > > set(true) > > > > > > let accessor: Lens = #lens(controller.view.isVisible) > > > print(accessor.value) > > > accessor.value = true > > > > > > This would have the added bonus of also tracking the reassignment of > > > reference-type properties - in this example, if 'view' is reassigned, the > > > referenced value is updated. > > > > Sounds good, I'm not aware of this syntax. Will investigate, thanks. > > Sorry, I was suggesting a *possible* syntax. No such syntax currently exists, > though the functionality can be imitated with closures: > > let get: () -> Bool = {controller.view.isVisible} > print(get()) > > let set: (Bool) -> () = {controller.view.isVisible = $0} > set(true) > > struct Lens { > var get: () -> T > var set: (T) -> () > var value: T { get { return get() } set { set(newValue) } } > } > let accessor: Lens = Lens(get: {controller.view.isVisible}, set: > {controller.view.visible = $0}) > print(accessor.value) > accessor.value = true > > > It's a bit more verbose when creating the get-set accessor, and may not > perform optimally, but it's actually pretty functional. > > > > > > > > > 5. Memory / pointer access, including casting. It's too verbose > > > > currently IMO when compared to C. Should be better supported for a > > > > language that is also targeting low-level (network, disk storage). A > > > > syntax that is both fast (like C) and safe would be great. > > > > > > Not familiar with low-level programming in Swift, but have you considered > > > creating domain-specific operators? > > > For example, I imagine something like 'UnsafeMutablePointer(v)' could be > > > reduced to '*v'. > > > > > > > > > > Do you mean operator is available only within a limited scope? That would > > be interesting, because I don't want to pollute global scope with such > > all-purpose operator. Sounds that I need to investigate that as well. > > If you have a specific module which performs this sort of operation a lot, > you can just declare the operator as internal. If it's needed in several, > making a separate module for the operators could be preferable. > > > > > > > 7. I'm also fan of async/await kind of stuff, asynchronous flows, etc., > > > > but this has already been mentioned -> cool! > > > > > > I would like to see some ideas in this area. > > > async/await never really clicked for me until I realised it's just > > > syntactic sugar - 'await' actually ends the function, and everything > > > below is an implicit callback. Personally I feel like Swift's trailing > > > closure syntax makes callbacks lightweight enough that this isn't so much > > > of an issue. Something focusing more on the memory-management and > > > thread-safety aspects of asynchronous code does seem useful in the > > > context of Swift. > > > > > > > > > > > > Sure thread-safety, atomicity features would be really nice & useful. > > > > The one problem I have with closure syntax (trailing or not, I like > > trailing too), is that when you chain a few of them, which is pretty > > frequent is async programming, you end up with a closure pyramid. It > > doesn't scale well beyond 2 or 3 levels. > > Makes sense. _______________________________________________ > 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
