forge-std icon indicating copy to clipboard operation
forge-std copied to clipboard

Feature request: adding console.log(string,bytes32)

Open 0xPhaze opened this issue 2 years ago • 5 comments

I often find myself needing to log bytes32 and currently this only works with console.logBytes32. Is there a possibility of extending console to add in console.log(bytes32) or console.log(string,bytes32)?

0xPhaze avatar Jul 15 '22 16:07 0xPhaze

Related: https://github.com/NomicFoundation/hardhat/issues/1440

PaulRBerg avatar Jul 15 '22 17:07 PaulRBerg

Maybe console2 could pick up these changes quicker than waiting for changes to console. And couldn't I just be required to explicitly cast to bytes32 in the case of ambiguity. For example: console.log('var', bytes32(0x1337)). This would still be a nicer UX compared to console.logBytes32, imo, but either is good.

0xPhaze avatar Jul 17 '22 08:07 0xPhaze

I agree, not having to use console.logBytes32 would be a better DX.

PaulRBerg avatar Jul 17 '22 09:07 PaulRBerg

I'd say PRs for things like this into console2.sol are good, but we should leave console.sol 1:1 with hardhat. @ZeroEkkusu let me know if that seems reasonable.

And couldn't I just be required to explicitly cast to bytes32 in the case of ambiguity. For example: console.log('var', bytes32(0x1337)). This would still be a nicer UX compared to console.logBytes32, imo, but either is good.

Yea if there's ambiguity in your call solc will just force you to cast and be explicit, which I think is ok

mds1 avatar Jul 17 '22 23:07 mds1

Agree with console/console2.

ZeroEkkusu avatar Jul 18 '22 07:07 ZeroEkkusu

Is there a possibility of extending console to add in console.log(bytes32) or console.log(string,bytes32)?

As hinted at above, the reason it's console.logBytes32(bytes32) and why we shouldn't add support for console.log(bytes32) (and similar for the overload with a leading string arg) is because then something like console.log("x") becomes ambiguous, as solc doesn't know if "x" is bytes32 or a string. So this would end up being a big breaking change for users by requiring type casts to existing code. As a result I'm going to close this 🙂

If you'd prefer the overload + required casting, I'd suggest leaving a comment on https://github.com/foundry-rs/foundry/issues/3782 since there may eventually be a vm.consoleLog type of cheat

mds1 avatar Mar 09 '23 21:03 mds1