[Pitch] Weak let

At a semantic level, you must understand a weak reference as its own kind of value. It is bound to a specific object, but when you try to read it, you cannot always retrieve the object anymore because the object might have gone away. That changeability is inherent to weak references. Nonetheless, it is still logically the same value and will remain so forever: a weak reference bound to the original object. That is not the same as being mutable because it cannot be replaced with a weak reference bound to a different object.

I understand why people are attracted to this idea that weak references are actually spontaneously mutating themselves. Mutating a class reference is a concept you’re already comfortable with, and if you think about the implementation, of course there must be some mutation there to allow the object’s memory to be reclaimed. But the idea doesn’t really work as a model of the language, among other reasons because it implies such a strange way of thinking about structs that contain weak references — you suddenly cannot ever talk about them as values again, because they are always variables that can be mutated. I have seen people go so far as to say that Swift shouldn’t allow weak references in structs because of this, all in service of trying to hold on to their mental model of spontaneous mutation.

27 Likes