First, I want to make absolutely clear I'm not criticising anyone. I'm just talking about my thoughts on how to use Swift, basically so that people reading this thread can think "it's OK, I don't have to worry about this"!
What I mean by "a slightly dangerous type of thinking" is this...
I have worked in a lot of languages over 30 years, swift is just my most recent. Often people try to "game the compiler", i.e. developers say "although they look the same and in theory these two constructs should do exactly the same thing, you should always use this form X not that form Y because the compiler will compile it better".
The problem is, you are trying to second guess an extraordinarily complex software system (all of the 100 or 200 optimiser passes that run on your code at various levels during lowering, SIL transforms, IR transforms, MC emission, etc.)
And it's a moving target. In one specific case, on the first thread, with one specific version of the compiler on one platform, there was a path where two identical looking approaches happened to optimise differently. The fact that the developer was returning a Bool constant true or false would absolutely have been important too... constant transformations would probably apply (to be sure you would have to reproduce the exact behaviour then turn on detailed optimiser debugging to detail exactly what transforms were done on each code path... this would be something like a few weeks work done by a normal person). It could easily be that if they had returned a float, or if they had added two constants together, or returned a string, then the result could have gone the other way... the static let
would have optimised better and the computed property would have been slightly slower. Or most likely they would have been the same. This is almost certainly not as simple as "if you use the Swift 5.1.3 compiler then computed vars are faster than static lets in all cases, they fixed the issue later".
In the second thread it's even more cut and dried. The OP admits that the two ways to write the code produce exactly the same SIL, therefore exactly the same IR and the same machine code when optimisations are turned on.
There is a bit of discussion by Jordan about what happens in the complicated case where a static computed property and a static let are exposed from a library. But again, this is a very complex case. How much can be optimised will depend on what's public, whether the library has been built resilient and if the properties are @inlinable
, etc. and I'm sure he'd agree that it's not as simple as "computed vars are more efficient".
I would say the general rules for static let vs computed properties (in the context of the OP's question) are simple:
- using either will produce the correct behaviour
- if you are not crossing module boundaries, i.e. if the code for the static let or computed var properties are all in the same module (they will usually be for most normal iOS apps you write for example) and if optimisations are turned on (usually most release builds in Xcode will have optimisations turned on) then the two approaches will produce identical code in almost all cases and be equally "efficient"
- in the (rare) cases where a particular combination of compiler version and code produces a difference in speed, it could just as easily be static let that's faster and not computed var. You are not going to be able to predict it and you probably shouldn't try. A slight change in code or compiler version might reverse the result and make it a slower approach.
- even if you happen to get it right, the differences are likely to be so small that you'd never notice
So, in summary, the reason I call this type of thinking "slightly dangerous" is because 1) it leads to "cargo cult" programming (see Richard Feynman) where people do things but they don't know really why, 2) it will often produce distractions from simple, understandable code that is readable and makes sense, for no benefit, 3) in some cases it might make it slightly faster or slower but either way it almost certainly won't be reliable and probably won't be worth it.
I hope everyone takes this in the spirit in which it is meant... as reassurance that you don't need to worry and can write what seems like elegant code... and not as a criticism of someone's work!
p.s. Just to give a little context, while I am no expert. I've written swift code since version 1.0, contributed small patches to the compiler and I make my own variant of swift and the standard library for Swift for Arduino. This is how I've seen a lot of the details of optimisations in practise... with many, many hours of studying the AVR machine code output at the end of the process!