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

> if it's worth emitting a warning, it's worth emitting an error. There is a semantic difference between a warning and an error: - An error indicates a _violation_ of...

I think this issue would be a "good first issue" btw

Fully support disabling reentrancy by default. @charles-cooper if you need hard stats, you can simply link to my reentrancy attacks list: https://github.com/pcaversaccio/reentrancy-attacks. Also, for the sake of completeness, I cross-reference...

One comment regarding `view` functions. You can't disable reentrancy by default for `view` functions since it would require a state changing operation as part of the tx. Thus, question is...

> the `nonreentrant` modifier can be used on `view` functions, see #2921 So you want to keep this decorator as well?

For the sake of documentation, linking a very interesting write-up by @0xalpharush on the discussed matter: https://gist.github.com/0xalpharush/15d903ec43334b081caece21a0bd7a20. Also, @jtriley-eth provided interesting thoughts (in Solidity tho) for reflection.

> I support this a lot, but I have a couple ideas/questions, I am not sure how useful this one would be but having @reentrant(5) to allow a specific number...

> To be honest I doubt this actually sees much if any use, but think it would be good to have in edge cases. Like for example in the code...

FWIW, dex aggregators like 1inch also use reentrancy as a feaure. Also there, we should conduct an impact analysis.

> it seems the preferred implementation in terms of language design will be to remove the current @nonreentrant decorator and replace with an @reentrant decorator (with inverted semantics) how about...