Thanks for taking the time.
One of AVAsset's potentially blocking computed properties is
var duration: CMTime. If the asset isn't downloaded already, it will block, so it's still O(1) amortized.
This kind of example seems to me to be missing the point. Like, yes, you could design an API (and apparently AVAsset is designed this way), but why would you want that, as the consumer of an API? I can't imagine a situation where I'd not care whether the access of duration might block indefinitely.
In general, implicit caching causes headaches. UIViewController has a similar problem (though synchronous): view with its implicit caching behavior is almost never what you want. viewIfLoaded and loadView() are a more useful API surface. I find it better to model the state transition explicitly in the type system. For example, you might have
class LoadedAsset {
let duration: CMTime
}
async func load() -> LoadedAsset
or if it's a kind of partial stateful streaming thing, you might go to the UIViewController approach:
struct Properties {
var duration: CMTime
}
var propertiesIfLoaded: Properties?
async func load() -> Properties
I guess it seems more to me that "the design of AVAsset is wrong" than "this proposal solves a real problem for AVAsset".