This has been briefly discussed in #1247 too.
Vyper still only outputs the constant and payable fields. The stateMutability field was introduced a while ago (probably 2 years ago?) to supersede both constant and payable as well as to support more granularity:
pureviewnonpayablepayablepure means the function doesn't execute state modifying and neither state reading instructions; view allows for state reading instructions; nonpayable allows modifying the state, but no incoming ether transfer; and payable allows modifying the state and incoming ether transfers.
It would be nice add support to Vyper to also output this field.
Are there any reasons against it?
No, it looks this was missed in #1244. We can make this happen.
@fubuloubu are there any updates on this?
Not started yet, but it should be fairly easy to add if you want to give it a shot. We're planning on a release, hopefully in the next week or two.
Appears there might be some work to determine pure if you think that would be important to add, but the new type system @iamdefinitelyahuman should make it easy enough to query if self is used inside a method.
Yes, shouldn't be hard to search for self. We can and should implement this in the upcoming release.
As of #2049 we can handle ABI inputs with either stateMutability or constant/payable set
Do you support all the various states? And does the generated ABI JSON contain the stateMutability field?
Not yet, #2041 and #2042 will complete support of all 4 states in both contract definitions and interface definitions, as well as output the field
@axic just to confirm, once we add the stateMutability field, we should drop constant/payable? (but retain support for processing both)
once we add the stateMutability field, we should drop constant/payable? (but retain support for processing both)
It is up to you. Solidity stopped outputting constant/payable with 0.6.x because the stateMutability feature was introduced 2 years ago. This showed that two projects did not made the update: ethers-js (fixed since) and geth (they use some ancient web3.js for the console -- not fixed yet).
It seems it won't be detrimental if you stop outputting it, but I'm not entirely sure if there are frameworks specifically made for Vyper and if they depend on it (truffle, buidler, waffle should be fine).
@iamdefinitelyahuman Brownie is okay with this, right? I think web3py handles this well
Yeah, Brownie understands both formats.