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

[James Froggatt]

You make some interesting points. My feedback's inline.

> 1. Swift is very good for lots of stuff. My favorite is code clarity and conciseness. Math code is great in Swift too (where I typically used Obj-C++ previously). I can feel the potential of development going faster and code getting safer at the same time. Love it.

Same. Another one of my favourites is optionals, and non-nullable references by default.

> 2. Need for static libraries (or equivalent): let me give you an example of how we organize our code. We have an image processing library, XXX, which currently has 2 backends : XXX+Metal XXX+OpenGL. Orthogonal to that, another extension allows JPEG file export using a third-party encoder, XXX+JPEG. Another feature, for when we need to process video buffer, XXX+CoreVideo which provides handling of native pixelbuffer. All of these are curently made as static libraries (5 libs for XXX and extensions) that can be linked into the app depending whether they are needed or not. Framework could technically be used too, but that is both inefficient (why link the code at runtime? Launch delay, etc.) and it does not scale (we'd need 20 frameworks to build a single app).
> 
> Swift, with its extension concept, is very well suited to modular development like this. We'd like to have a better option than frameworks to build reusable libraries. It's not an ABI thing, we really don't care about that, we use libs just to organize code, building them as a part of the app, and *not* to provide precompiled libraries to some other developers. Swift package manager does not work well within Xcode either at this time, and has a number of constraints we don't want (like having a separate git repo for each static lib -> that's not practical at all if you just have 1 or 2 files in that lib).
> 
> I met 4 people at WWDC from both Swift and Xcode teams, but I'm not sure this topic went through. This is a major concern: organizing reusable code efficiently is what will bring Swift into larger projects where it could really shine. We're currently using a hack to enable modular development in Swift (static libs), and that should be addressed as fast as possible, all languages have that, we shouldn't wait for Swift 5 or 6 to get it. This is by far our number one concern with Swift.

Agreed. Frameworks really aren't enough.

> 3. Fixed-size Arrays are missing. They are useful in some contexts like:
> struct Quad { CGPoint corners[4]; }
> using a let array makes values immutable, using a var Array makes array *size* mutable, which is not what is needed here. 

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)'.

> 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.

> 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'.

> 6. Explicit casting between numeric types (CGFloat / Double / etc.) are cumbersome, or Int and float types. Some kind of auto promotion would be nice.

I think Swift generally favours being explicit, and while implicit conversion where no data loss occurs would be nice, it could also could be easily misused. This is a tricky problem.

> 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.

> Thank you for reading.
> 
> Raphael
> -- 
> Raphael Sebbe, @rsebbe (twitter)
> creaceed.com — Apps for Mac • iPhone • iPad
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160804/75628590/attachment.html>