Thank you Chris, James. I'm answering James feedback/questions below.
On Thu, Aug 4, 2016 at 1:57 AM James Froggatt <[email protected]> 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. > 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<Bool> = #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. > > 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. > > 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. Raphael
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
