I’m not sure if I like it, but declaring it as a let could disallow subclasses from overriding it, just like any other let.
- Dave Sweeris > On Apr 23, 2016, at 2:30 PM, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > I already see the problem here: > > class A { var x: Int { return 42 } } > class B: A { override let x = 7 } // assume that will work > class C: B { override var x: Int { /* wait this wont work anymore */ } } > > You won’t be able to override an immutable constant. > > I don’t like such a change. > > -- > Adrian Zubarev > Sent with Airmail > > Am 23. April 2016 bei 21:19:27, Roman Zhikharevich via swift-evolution > ([email protected] <mailto:[email protected]>) schrieb: > >> I think, it could be a good idea to make computed properties overridable >> with let constants. >> >> Something like this: >> >> class Parent { >> var x: Int { >> let x = 42 >> /* >> * Compute x... >> */ >> return x >> } >> } >> >> class Child: Parent { >> /* >> * Sometimes you need to override computed properties with simple >> constants. >> * This is currently done like this. >> */ >> //override var x: Int {return 7} >> >> /* >> * But this looks neater. >> * Currently this gives "error: cannot override with a stored property >> 'x'". >> */ >> override let x = 7 >> } >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
