[swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

[Manav Gabhawala]

> > 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 (swift-evolution at swift.org(mailto:swift-evolution at swift.org)) 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution