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

[Raphael Sebbe]

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.

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.

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.

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.

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.

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.

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

Thank you for reading.

Raphael
-- 
Raphael Sebbe, @rsebbe (twitter)
creaceed.com — Apps for Mac • iPhone • iPad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160803/f95cbbc3/attachment.html>