3

Why I can override a stored property with a computed property, but I cannot override a computed property with a stored property?

class SuperClass {
    
    var property1: Int = 0
    
    var property2: Int {
        get { 0 }
        set {}
    }
    
}

class SubClass: SuperClass {
    
    override var property1: Int {
        get { 0 }
        set {}
    }
    
    override var property2: Int = 0 // error: Cannot override with a stored property
    
}
Fawzi Rifai
  • 533
  • 1
  • 4
  • 12
  • That's like asking why a goal is 1 point. Those are the rules. Well, what you've described are the rules of the Swift language. A property override MUST be a computed property. End of story. To use the language, obey the rules. – matt Oct 23 '21 at 13:26
  • 4
    @matt That’s silly. People expect to be able to understand the systems they work with. Asking for the technical basis for a particular restriction is something we should embrace, and I think you’re being senselessly dismissive. Would you prefer the alternative, people mindlessly following along compiler messages without cultivating any understanding as to what/why is going on? – Alexander Oct 23 '21 at 13:28
  • Well maybe there is some other sense of the word "why", like why the Swift language is designed like that. But that is a matter of opinion. Of course I have an opinion and so do you, and it is probably right, but it's just an opinion. – matt Oct 23 '21 at 13:30
  • 2
    As [The Swift Programming Language](https://docs.swift.org/swift-book/LanguageGuide/Inheritance.html#ID196) says, “You can override an inherited instance or type property to provide your own custom getter and setter for that property, or to add property observers to enable the overriding property to observe when the underlying property value changes.” You just can’t override with a stored property. – Rob Oct 23 '21 at 13:37
  • 1
    @matt That's totally not true. There are plenty of language design decisions that have very clear-reasoned intentions, sometimes ones that are even explicitly documented. This doesn't apply to all choices of course (e.g. why is "func" not "fn" or "function" was just kind of a first choice that never got revisited, with no deeper underlying reasoning), but many. E.g. "Why doesn't Swift let you mutably capture a struct"? "Because that would allow you to alias structs and effectively make them into value types". That's not opinion based. Anyways, without asking, you couldn't know. – Alexander Oct 23 '21 at 13:37
  • @Alexander Well, we don't agree on how to handle questions of this sort. And that's fine. – matt Oct 23 '21 at 13:50
  • Does this answer your question? [Overriding a stored property in Swift](https://stackoverflow.com/questions/26691935/overriding-a-stored-property-in-swift) – Scott Thompson Oct 23 '21 at 14:16
  • @scott-thompson no. – Fawzi Rifai Oct 23 '21 at 14:30
  • @FawziRifa'i _Why_ doesn't https://stackoverflow.com/questions/26691935/overriding-a-stored-property-in-swift answer your question? – matt Oct 23 '21 at 15:20
  • I think it has to do with memory management. A computed property does not allocate extra memory. It doesn’t need it. Now you want to make it a stored property. It needs to allocate space for that property. Now imagine casting your class to the base type. Is the space allocated or not? I believe a compiler will first allocate the space for the base class and then for your inheritance. Plus it’s weird. It’s like method swizzling where you change the behaviour of a property to make it settable and while you can extend classes and change them you can’t change the access levels. – Jacob Oct 23 '21 at 16:32
  • @Jacob - Allocation of more memory is not the issue: Subclasses frequently have additional stored properties. (It’s only the _overriding_ with new stored property which is prohibited.) You're right, though, that “it’s weird”: Overriding with a stored property has lots of messy and unintuitive implementation details. The whole notion of overriding with a new stored property is a questionable, IMHO. Certainly doesn't make my list of things that I'd like to see in the language. – Rob Oct 23 '21 at 20:59
  • @Jacob That's a problem in C++, but the Objective C runtime actually calculates variable offsets at program-load time, so that base classes can safely add/remove instance variables, and the instance variables of base class automatically have their offsets adjusted to make things work. Check out https://www.cocoawithlove.com/2010/03/dynamic-ivars-solving-fragile-base.html – Alexander Oct 23 '21 at 21:32

0 Answers0