Is a Swifty version of
NSCache on the cards for Foundation?
NSCache is great for its thread safe behavior and support for automatic purging of items under memory pressure. Unfortunately it doesn't fit so nicely into the type-safe and value type world of Swift. In particular, although it supports lightweight Objective-C generics that are bridged to Swift, it requires that the
ObjectType be Objective-C classes.
This means you can't store Swift Foundation value types like
Data in an
NSCache and instead have to use/bridge to
NSData and the like.
To use it more "generically" with Swift you have to wrap
NSCache in some sort of Swift wrapper that bridges the worlds. This sort of thing would be easy to get wrong and seems like an ideal candidate for Swift's Foundation wrappers. A
Cache class in Foundation would be rad.
NSCache has its own issues and there're various reason why it's not a popular type, even in Objective-C, which is likely why it hasn't been given much love in Swift. If you want this discussion, perhaps a brief outline of the API you want for a Swifty
Cache type would be good.
Personally, I think effort would be better spent creating a native Swift version of a type with similar features. However, given there's no place for such a type to live at the moment, I guess we're stuck.
Someone could develop a useful alternative as a library independent of the standard library or Foundation. If it gets wide enough use and the design seems to hold up, we could consider it for the standard library if it were submitted.
Not to restate what I've said in numerous threads before, but that reasoning is deeply flawed, given there's no actual process for integrating such a popular library. Also, given the fragmented nature of dependency management on Apple's platforms and Swift in general, there's little reason to believe such popular dependencies will emerge organically. Until Swift has the ability to publish "official" dependencies outside the standard library, I doubt something like this will ever happen.
That may be true now, but there's also a bit of a feedback loop. The ecosystem needs libraries to populate it, and libraries need a robust ecosystem to distribute to. We have a lot of work on our side to build that dependency management infrastructure and package ecosystem, as well as figure out how exactly to establish, maintain, and promote core libraries, but I don't think people should be discouraged from trying to solve their immediate problems by building libraries either.
That isn't what I'm saying, and I'm aware of work, both ongoing and still needed, towards a robust dependency culture for Swift. To be blunt, my point was that every time someone says a popular library could be integrated into Swift, I see it as a cop out, given that it's currently impossible for that statement to be true (or it's stated so vaguely as to include deniability in the statement itself). It's used to cut off discussion of a variety of limitations in the Swift development process and Foundation, most revolving around the limited resources available or the control Apple wants to continue exerting over the language as a whole. Frankly, until such a process is actually in place (and perhaps demonstrated successfully), it isn't productive to bring it up.
OK, that's a fair assessment. I read your original post as saying "don't even bother trying to solve this problem because there's no way it'd end up in the standard library/libraries", which wasn't really what you were saying.
We're open to some ideas on how to improve
NSCache for Swift. We didn't drop NS on it because we knew it would be one of the types that needed some work to feel great in Swift.
One of the trickier areas is indeed value types. What do you see as the correct behavior of a value type in a type like