Compile‑time error when reassigning an immutable variable to its current value in Vyper

Answer

Yes. The Vyper compiler emits a compile-time error whenever you attempt to assign a value to an immutable variable after its initial initialization, even if the assigned value is identical to the value the variable already holds. The compiler does not treat such a reassignment as a permissible no-op.

Confirmed facts

• The error message contains the name of the immutable variable and the exact source location (file name and line number) where the illegal assignment appears.
• This behavior has been present since Vyper 0.2.0 and remains unchanged in the 0.3.x series and later stable releases. The exact wording of the error may vary slightly between versions, but the inclusion of the variable name and line number is consistent.

Likely explanation

The immutability check is performed syntactically at compile time: any assignment statement targeting an immutable after its initialization is treated as a modification attempt. The compiler does not compare the assigned value against the current value, so conditional-initialization patterns that re-assign an immutable to its current value will still trigger the same error.

Verification steps

1. Create a Vyper file, for example test.vy:

# test.vy
VALUE: public(immutable(uint256))

@external
def __init__():
    VALUE = 42

@external
def test():
    # Attempt to reassign the same value
    VALUE = 42

1. Install a specific Vyper version, for example pip install vyper==0.3.10 (repeat with 0.2.x or 0.4.x to compare).
2. Compile the contract: vyper test.vy.
3. Observe the output; you should see a compile-time error naming the variable VALUE and pointing at the reassignment line.

Note that immutable syntax differs across versions (0.2.x uses VALUE: constant(...)-style declarations in some contexts and 0.4.x uses the immutable(...) form shown above), so adjust the declaration to match the version under test. If your observed error output does not include the variable name or line number, report the exact compiler version, since that would contradict the expected behavior described here.