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

right - you are absolutely correct, I just tested that as well. But still, it doesn't feel right to use that modifier twice. Also, I would strive for some consistency...

> @pcaversaccio since internal is now optional, should `@payable` imply `@external`? Hmm, I personally dislike implied behaviour. I think it could be confusing that functions are now `internal` by default...

This currently compiles and would imply for both functions an `internal` behaviour. If we imply via `@payable` `external` behaviour this might be a breaking change, no? ```vy @payable def _sending()...

For me `payable` is an `external` feature. The semantics behind `payable` is that it's "the possibility to receive value via an _`external`_ function call". An `internal` function doesn't directly receive...

> Hey @pcaversaccio > > For Foundry we are looking to default to Prague, do you happen to know from what version Vyper supports Prague? > > Ref: https://github.com/foundry-rs/compilers/blob/507cd414fa374b50bb3d58f7501f5e477b73a9c8/crates/artifacts/vyper/src/settings.rs#L15 @charles-cooper...

Can confirm the inconsistent behavior. Let me document another example, the `ERC721` interface: If you do something like the following (without `data: Bytes[1024]=b""`), the compiler will not throw even though...

Yes, I agree with you @Amxx - the examples you provide are much more spot-on. Let me give another example I've seen among developers. Some people assumed that `uint` is...

I would like to add another (honeypot) example where the `uint` alias creates an issue: ```solidity contract B { function claim(uint amount) external payable { payable(msg.sender).transfer(amount * 2); } fallback()...

This issue is still relevant.

Don't close as this issue is still relevant.