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

[Dave Abrahams]

on Thu Aug 04 2016, Manav Gabhawala <swift-evolution at swift.org> 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
> (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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave