Allow initializing immutables in parallel branches of try/catch statement

[Amxx]

Description

The current compiler prevent having multiple initialization of a immutable variable, even if the are in independent branches. It would be nice if this was supported.

Environment

• Compiler version: 0.8.16

Steps to Reproduce

pragma solidity ^0.8.0;

interface IERC20 {
    function decimals() external view returns (uint8);
}

contract Example {
    uint8 public immutable decimals;

    constructor(IERC20 asset) {
        try asset.decimals() returns (uint8 value) {
            decimals = value;
        } catch {
            decimals = 18; // This causes an error. IMO it shouldn't
        }
    }
}

[StrongerXi]

Would like some inputs from the maintainers.

If this is worth to fix, I can try throwing another PR on top of #12878 to further relax the immutable checker.

[cameel]

Previous issue about conditionals: #12864.

If we're fine with doing it for ifs, I don't see any reason not to for try/catch as well.

[StrongerXi]

~Cool! I'd like to start this once #12878 is merged.~

Edit:

A more general approach is preferred (to handle arbitrary control flow for immutable variable validation).

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

[Amxx]

this is still relevant , please don't close it.

[cameel]

Actually, there was more discussion about this in the PR (https://github.com/ethereum/solidity/pull/12878#issuecomment-1298411608) and in the end the issue will be solved differently, by removing the restriction on initialization in constructor, which is a part of the roadmap task to add dynamic immutables (#13723). As such, @ekpyron did not think it was worth keeping open as a separate task the last time we talked about it.

[ekpyron]

Yeah, it's not. There's always the short-term workaround to just define a local variable for this - and with #13723 the rules and restrictions will change significantly, which will solve this issue implicitly, so in this sense, this falls under #13723.