on Thu Aug 04 2016, Manav Gabhawala <[email protected]> wrote:
>> > 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. True, but the inefficiency of that approach pretty much defeats the purpose of having a fixed-sized array. > > 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 -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
