2

Swift extensions cannot contain stored properties:

Because properties need storage, adding properties would change the memory structure of the class

If we look closely at the runtime class struct, the Ivar list holds the property storage, and the method list also holds details about the methods that invoke the class objects. And extensions add features in the form of methods to the classes. The extraSpace in a class struct holds the extension struct. Since we can add methods to extensions this way even after the objects have been created -- and to hold the extension methods, memory has to be allocated -- why can't we add ivars?

jscs
  • 63,694
  • 13
  • 151
  • 195
rishu1992
  • 1,414
  • 3
  • 14
  • 33

1 Answers1

4

Because extensions apply to the entire type (struct/class). ivar storage must be allocated for each instance, and instances may already have been created by the time the extension is added to the system. The metatype information can be updated; all the existing instances (which may be stored inside of other instantiated types) cannot be. There is no list of "all existing instances" that you could go and reallocate (as well as reallocating their containers).

Remember that extensions can be applied by other modules, so they may be dynamically attached whenever the module is loaded (which is not even promised to be at launch time at all, let alone before code starts running).

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • _"instances may already have been created by the time the extension is added to the system"_ ...because you can extend types from other modules that may have been loaded already. I can't think of any _inherent_ reason that same-module extensions couldn't add storage; is there one? (It would complicate everything, so not saying it's a good idea to allow it...) – jscs Jan 18 '19 at 17:11
  • 1
    It might be possible as long as you always compile with whole module optimization. But with incremental compilation, I would expect it to be much more complicated, and potentially impossible with static dispatch. Clearly there is some way to know about extension methods without WMO, so it's not like C where every file is compiled in a total vacuum, but there still is some separation when performing incremental builds. Still, it might be possible some day. – Rob Napier Jan 18 '19 at 17:15
  • I couldn't understand if we could add methods in an extension which also needs storage (SEL, IMP, name) similarly, storage can be allocated for iVars right? – rishu1992 Jan 19 '19 at 04:06
  • The SEL, IMP, and name aren't stored anywhere in Swift. Swift is primarily statically dispatched, not dynamically dispatched, so there's no need for a method table in many cases. But in cases where there is dynamic dispatch and some sort of vtable (using a witness table, but let's not split hairs here), that can be allocated in one place on one data structure for a given type. There is no equivalent data structure for "all instances of a type." It's not that it's completely impossible to create such a thing (ObjC does it via associated objects), but it has costs, and Swift hasn't gone that way – Rob Napier Jan 19 '19 at 20:43