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

[Raphael Sebbe]

Thank you Chris, James.

I'm answering James feedback/questions below.

On Thu, Aug 4, 2016 at 1:57 AM James Froggatt <james.froggatt at me.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160804/a968e8bb/attachment.html>