inter-module optimization?

There is currently no way to do what you're asking for.

It would be great if you could open a bug report suggesting this for future consideration.

I have created a bugreport.

We have the same issue with a project which consists of roughly 40 modules.

Also incremental compliation is not working across module boundary. E.g. if you change a Swift file in a module, all dependent modules will be rebuilt completely (even if the modified type is private!).

Regarding the optimization issue:

I think the most important optimization of Whole Module Optimization is eleminating dynamic dispatch, which results in faster code. This is possible because it can evaluate all usages of non-public properties and functions. If they are never overwritten in a subclass it can avoid dynamic dispatch.

You can perform this improvement manually using the "final" keyword on all classes, properties and functions which are not overwritten in any subclass in any module of your app. We for example always mark all our classes as "final" and remove the keyword only if we really cannot avoid sublassing the class.

You can read more about dynamic dispatch here: https://developer.apple.com/swift/blog/?id=27

So your solution is to emulate the broken C++ design by hand?

I don't know what you mean by broken C++ design but as long as there is no Whole Project Optimization you'll have to make the optimizations manually.

Broken design: all methods are final except when the developers say otherwise. Methods are intended to be overwritten so this goes against the very essence of oop.

May be surprised for your: Swift is not a pure OOP language.

There's not wrong put final in all classes at beginning. In the fact, considering the capabilities of protocols (like defaults methods) and `value type` programing, the idea of subclasses may be not be necessary at all.

We are stuck with OOP because Cocoa is a OOP framework, but we can make ours classes without these "essential" patterns of OO.

Why are people fighting so hard against oop? Swift is a generic/object oriented language by design. But all I see here tries to make it functional, aspectdriven etc instead of acepting the design choices made for Swift.

Because these is not the entire story:

Protocol-Oriented Programming in Swift

https://developer.apple.com/videos/wwdc/2015/?id=408

I never considered Swift as primary OOP language like you said, and most of entries on WWDC and Swift official Blog posts also....

Useful value types and protocols is the greatest achievements of Swift, not generics, and not any kind of objects.

But if you like OOP, it's Ok in Swift too... But just that...Ok.

Swift's standard library has: 94 structs, 74 protocols and 5 classes.

(And I can only see one case of inheritance (the ManagedBuffer class inherits from the ManagedProtoBuffer class).)

So if OOP is about objects with identity (ie instances of classes in Swift) that interact with one another, then at least Swift's standard library is not OOP.

Swift's standard library is designed in a way that is totally different from a typical Objective-C or let's say Java framework where practically everything is about objects with identity (classes that inherits from NSObject or Object).

And, as can be seen in the 2015 WWDC talk linked to by Wallacy: Dave Abrahams (technical lead for the Swift standard Library) says Swift is "the first protocol-oriented programming language".

Wikipedia describes Swift as "multi paradigm" and Objective-C as "object oriented".

But when people say OOP, they don't always mean something along the lines of Smalltalk/Alan Kay. So I think using fuzzy labels like OOP, FP and "multi paradigm" can often be rather pointless. Discussions have to be more specific.

Anyway, it seems to me that the support for Objective-C style OOP in Swift is just a means to an end: To leverage the power of the Objective-C Runtime and the Cocoa Frameworks (and perhaps also to make some "OOP-only"-oriented developers feel less uncomfortable).

The Swift Std Library is one thing: generic. There is nothing functional in it beside the functional based method in some types like map.

Here is the take of a big functional programming fan on Swift: http://robnapier.net/swift-is-not-functional