Conversions revamped
- Dominant language
- C++
- Stars
- 25.7k
- Forks
- 6.2k
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 21
Description
Currently we support (an ever shrinking number of) implicit type conversions and some explicit ones. The explicit conversions mostly truncate/extend, and only a single one (integer to enum) is performing a check and panic.
During #9170 we have endlessly debated whether converting from a larger bytes should truncate or throw a panic, and finally realised we may want to review how conversions work in general. It seems that we want to make in any way ambiguous conversions explicitly understandable.
In the past we discussed new casting/conversion syntax [here](https://gitter.im/ethereum/solidity-dev?at=5f63d5a3ce5bbc7ffdd03d46) and [here](https://gitter.im/ethereum/solidity-dev?at=6076e59381866c680c22168c):
> - We could consider C++ism `cast(cast(cast(1234))`) to make it worse (or use `convert<>`)
> - And add copyof on top of it: `cast(copyof cast(cast(1234)))`
>- `uint256(1234).as().as()` may be a bit more readable :)
> - I thought we had an issue proposing a syntax something like `cast(val)` instead of explicit conversions. I guess it is just more verbose so people would dislike it?
> - But at least would probably be easier to read `cast
> - If we do have cast<> as an unchecked casting, then we could later consider adding convert<> which does checks.
> - I wonder if we could use the cast syntax for multiple-step casting, i.e. `cast(..uint256 input..)` or `cast int128 -> int16>(..uin256 input..)` (similar to the mapping syntax)
> - But the other option we briefly discussed is explicit casting works like static_cast/reinterpret_cast and we could introduce truncation/conversion helper on the types, i.e. `bytes32.truncateFrom()`.
> -Instead of the multiple step casting I suppose there could be nicer helpers in the stdlib doing that?
To summarise, the following syntactical ideas were proposed:
- `cast(from)`
- `convert(from)`
- `from.as()`
- `cast()` (in case of a series of conversions)
- `bytes32.truncateFrom()`
- `truncate<..>()`
- `extend<..>()`
On todays design call there seemed consensus to rather have explicitly understandable function names (such as `truncate` and `extend`), instead of a generic `cast`.
(Moved from https://github.com/ethereum/solidity/issues/9170#issuecomment-824035912)
Contributor guide
Research direction
Start by reviewing the conversion discussion in this issue and the linked context from #9170, including the proposed casting, truncation, and extension forms. The issue does not name implementation files or tests. Done would require an agreed conversion design, defined behavior for ambiguous cases, and an implementation plan.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, solidity
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100