Introduce selfdestruct as a new stateMutability level

[axic]

Propose to introduce destructible either above or mutually exclusive withpayable.

Reasoning: it is an even more elevated state mutability case, than payable, which could warrant its on level.

Benefits: mutability checker will be able to reject selfdestruct used in a method where it may not be desired. Also, libraries could have the callable check restricted to functions marked this way.

[federicobond]

Doesn't it make more sense to define that at the contract-level, maybe through a fake base contract? Then, the contracts cannot be destructed no matter which method is called/delegatecalled.

[axic]

I'm not at all fond of "fake base contracts". Perhaps pragmas?

[federicobond]

Yes, and the name didn't help either! I am not fond of pragmas because they apply to the whole source file. They seem like the wrong device to use here.

What about a constructor-only specifier? Makes sense to declare its lifecycle at the point of creation.

[axic]

Yeah, constructor specifier makes sense.

Also I don't think these are two mutually exclusive features, the above proposal is defining whether selfdestruct can be used within a function, while your proposal defines whether calling such a function is legal in a contract.

[federicobond]

Let's take the following code example:

contract Auction {
  // ...
  function endAuction() public {
     // do some stuff and let users define custom behaviour in finalize
     finalize();
  }
}

contract MyAuction is Auction {
  function finalize() destructible internal {
    selfdestruct(owner);
  }
}

I assume endAuction requires the destructible specifier too. If that's the case, it becomes hard for generic contract authors to know whether to put destructible specifiers in all functions that are meant for extension or none, which could limit the options of users down the road. Am I missing something?

[fulldecent]

There should be consistency between:

• State mutability in interface specifications (payable, default non-payable, view, pure)
• Ethereum ABI (ABI is maybe not the best word choice)
• EVM opcodes

Currently we have parity

• payable, default non-payable -- CALL
• view -- STATICCALL
• pure -- PURECALL? <-- I need a link for this proposal

If we are considering to add a level that competes with these then effectively you are proposing NODESTRUCTCALL? I don't think there will be an opcode for that.

[github-actions]

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

[cameel]

I think we can safely close this given that selfdestruct is now deprecated (#13844).