Deniz Mert Edincik

> Well lets say the default impl of a destructor is to burn something because it does by default contain anything useful. Then you a dev add some escrow to...

@turbolent > The type checker should report an error for all special function declarations (e.g. initializers, destructors) with statements in interfaces, Add a test case for the new error above...

@joshuahannan yeah I messed up when fetching upstream I guess :( trying to fix

I think I managed to do all, just @SupunS's variable scope comment left, but I have no idea tbh how to approach that.

@turbolent I don't see the problem here, can you expand a bit? > that a default function does not have access to the members of the concrete type it is...

> Considering fields can not be extended currently for composite types I disagree with this consideration, this leads to bad outcomes. We should consider "how system should be" not "how...

> Improving efficiency when storing composite values Also I think here we need to make clear, what are we optimizing for. In this context I am guessing number of registers....

@ramtinms composite type extension is really important subject (at least for me), it is a bit bottleneck now, everyone is complaining, though it can be managed somehow even with these...

On post conditions before has weird behavior too. false || before(self.getBalance())>=0 calls getBalance, I know the reason but looks little strange

Oh btw @autoclosure seems to be the elegant way to do this in my opinion. Backwards compatible. Basically rewriting ast to if !assert(expression) { panic(message) }