Please consider supporting `unchecked` at the function-declaration level, in order to allow for cleaner code

Language Design
1

It is a typical scenario for an entire function to be implemented with native (unsafe until solc 0.8.0) arithmetic operations, in order to optimize its performance, and under the author’s knowledge of the function being robust for arithmetic overflows.

I have previously posted this request as an issue on Solc GitHub, but it has not been addressed since.

Thank you.

2

This is not under our development priorities for this year (2023), however, feel free to contribute with a PR or keep discussing it in the foreseeable future.

3

unchecked not affecting modifiers was intentional, so we won’t be changing that. It was to prevent unchecked arithmetic being hidden that way. We also won’t be adding a built-in modifier, because that’s just syntax sugar for an unchecked block that covers the function body. Given the big syntax chantes we have on the roadmap for the near future, we’d rather avoid adding more syntax like that. It may complicate the redesign.

Now, farther into the future, this might be doable as a user-definable modifier but we’ll see. Our goal is to make a lot of the stuff that’s currently hard-coded into the compiler user-definable and provided by the standard library. It’s too early to if this will also be the case for unchecked blocks.

1 Like
4

Just to contradict my previous posters on this one :-). We won’t accept PRs on this and this won’t be possible as a user-defined modifier in the future.

Just to give a preliminary outlook on the issue and our current position on this: We generally want to move semantic properties about types, like having checked or unchecked arithmetic, to where they belong, i.e. treat them as the properties of types, rather than as a property of context. That means that in the long run we will probably deprecate unchecked blocks in general, and rather allow defining (or ourselves define in a standard library) both checked and unchecked types (i.e. think better-named versions of checked_uint256 and unchecked_uint256 as distinct types, interoperations requiring explicit, though no-op, conversions).

An unchecked block or an unchecked function would then merely become a block/function that uses unchecked types.