warp
warp copied to clipboard
NethermindEth
Compiling cast of address to uint160
The following pattern is often repeated in solidity contracts:
uint256(uint160(addr)
Where the author's intent is to use the address as a number, Warp returns the following error when encountering this pattern:
TypeError: Explicit type conversion not allowed from "address" to "uint160". Warp changed address size to be 251 bits. Consider replacing uint160 casts with uint256 casts
Can/should this be implicitly converted to a felt (which is an address on starknet)? Any negative implications for this?
Implicit felt conversions break the type system and introduce classes of runtime bugs no solidity programer would expect from a transpile. For example, in the case a user tries to use an address as a number, they could reasonably try to pack it somewhere as a uint160 and we would break their expectations if they later try to read a uint160.
Adding an 'implicit' felt type to solc would be a maintenance nightmare which we want to avoid - we considered most of what would be required here when we thought of extending the solidity type system with an explicit felt type.
I doubt it's feasibly to identify uint256(uint160(addr)) cases in solc. Perhaps it is @swapnilraj?
I agree with Jorik that in general case doing an implicit conversion would break things in the runtime and there would be no-recourse for the programmer to fix it without reading through the generated code, which is bad UX.
On detecting the specific case of uint256(uint160(addr)) , I will have to investigate the solc typechecker. On first glance I think this is a good idea; it will require some special handling in the compiler it self. If we go ahead with this, we will emit a log informing the user of this implicit behaviour.
I have created an task for this that can be tracked on our project board https://github.com/NethermindEth/warp/issues/847
