sudo rm -rf --no-preserve-root /

EDIT: Non-issue for `view` functions. My example lacked a `implements: Self` declaration. ~~Further note: there is a similar bug for `view` functions. The following contract should not compile:~~ ```vy interface...

> Is there a missing `implements: Self` declaration? Good catch, thanks for pointing out @tserg! It's indeed a non-issue for `view` functions in that case.

Great observation @trocher! Yeah, my general point of view has always been that we must optimise for maximum correctness and thus I second enforcing the modifiability of the interface function...

I second this. Since the context is similar, I quickly link to my issue here: https://github.com/vyperlang/vyper/issues/3279. We should generally stop doing implicit `address` assignments IMO.

There are a couple of (library) use cases where "function overloading" using `self` would be helpful. What if we store the `self` address as an `immutable` at construction time as...

Quickly linking to this VIP https://github.com/vyperlang/vyper/issues/3701 which proposes to replace `self` (currently has type `address`) with `self.address` or `context.address`. This would imply the following code pattern, which I like: ```vyper...

I'm not sure whether this is intended behaviour or simply a regression tbh but if I use now the same variable name for the kwarg, it will fail:  ```vy...

> ``` > results.append(Result({success=success, return_data=return_data})) # This will raise > ``` > > The curly brackets are dropped in the new syntax, so this should compile: > > ``` >...

Also, I think it would make sense to update the docs [here](https://docs.vyperlang.org/en/latest/types.html#structs) with the new syntax.

> i don't think we need to spit a warning for `pure` vs `view`. but we could raise an error if the function is marked `>= nonpayable` but doesn't touch...