I feel like we have already deprecated SELFDESTRUCT. But it was never officially announced in the Yellow Paper or on the Ethereum Blog. This EIP fixes that.
We can implement this EIP now. It’s the first core EIP that does not require any client change, I think?
However, by implementing this we are putting customers on notice of a big upcoming change. And that is something that good software projects do.
Yeah I agree that this is a good idea. Anyone still deploying code with SELFDESTRUCT has been warned.
This should be a Meta-type EIP.
Here is some language in support of a meta EIP:
they are more than recommendations, and users are typically not free to ignore them
Changed to meta at Update eip-6049.md by fulldecent · Pull Request #6064 · ethereum/EIPs · GitHub
Thanks for this EIP, Will @fulldecent , I am curious could you elaborate the relationship this EIP vs EIP-4758: Deactivate SELFDESTRUCT
EIP6049 formally states that SELFDESTRUCT is deprecated, to tell devs not to create contracts that depend on it. As a meta EIP it can be quickly finalized. The sooner devs stop creating contracts depending on SELFDESTRUCT the easier it is to change the functionality.
EIP4758 is how SELFDESTRUCT can be deprecated by changing/removing functionality and will require an upgrade. It is not yet CFI’d, so at this rate might not be included in Shanghai upgrade and would have to wait for Cancun.
Oh, got it. If the purpose is to “call it out”, I guess it would be helpful to also mention the EIP-4578 and
EIP-4760 as context as “If you ignore, here are the consequence scheduled at Shanghai”?
Overall I am still debating myself with existence of EIP-4578 and EIP-4760, how much more value does a third Meta EIP brings to the table.
The pros I can think of having this third Meta EIP is (1) it can finalize faster (2) it record and signal an existing community consensus.
Would be nice if compilers (e.g. solc) will warn the user when violating a meta-EIP, or even consider it a compilation error unless an override flag is used.
I think it might be worth considering this for Shanghai, yes. Even though it’s just “symbolic”, getting a commitment from client teams that we are going down this route, and having a clear signal to users that “It’s happening 
!” is valuable, even without EIP-4758 or similar making it into Shanghai.
Anyone want to discuss this on the next ACD 
? Execution Layer Meeting 153 · Issue #704 · ethereum/pm · GitHub
Any reason this can’t be asynchronously proposed?
Oh, it can, but people just pay more attention through that (but mostly, via fork announcements). At the very least, we can post about this in the R&D discord and gauge people’s reaction.
