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

[Chris Lattner]

On Aug 3, 2016, at 11:11 AM, Raphael Sebbe via swift-evolution <swift-evolution at swift.org> wrote:
> Heard about the Swift 4 thing, so here are a few thoughts about the current version of Swift (3). We work on a sizeable code base, with a focus on modular code that is shared across our apps. Sorry if these things have been discussed already, just joined, and wanted to share a snapshot of our experience.

This is great, thanks!  Almost all of this are out of scope for Swift 4 stage 1, but this is great feedback.  Here are some comments from me, not speaking for the core team:

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

Great!

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

Makes sense.  This is something that I’d personally like SwiftPM to explore.  There is no specific reason that each swift package needs to be its own dylib.  I know the SwiftPM team is aware of this, and maybe there will be time to tackle it over the next year.

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

Yep, as James mentioned, this is sort-of handled with tuples today, but not satisfactorily (for a lot of reasons).  We should do better here.

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

The memory ownership work that is part of Swift 4 stage 1 may improve this situation, by introducing the notion of mutable references.  We’ll have to see how that works out.

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

Both of these are similar, I personally completely agree that we should have the ability to have “small fp” promote to “bigger fp” types.  This could be modeled by being able to define subtype relationships between structs.

> 7. I'm also fan of async/await kind of stuff, asynchronous flows, etc., but this has already been mentioned -> cool!

Me too, I can’t wait to get there, but we have to stay focused :-)

-Chris