Comment by Robert S Mozayeni (JIRA)

calebd (JIRA User) makes the case that this already works as it should, even if it is mildly inconvenient that d isn't supported. I've come to agree with him, but am still leaving this open for the Swift team to decided what to do with it.

Comment by Caleb Davenport (JIRA)

I understand the motivation for this (and have been in a situation where this would be nice) but I am not convinced that this is a bug.

Scenarios a, b, and c work because the symbol `x` is shadowing a variable in a new, more narrow scope.

`a` and `b` both create symbol `x` in a new scope by shadowing the function parameter `x` which comes from a higher scope. `c` creates a symbol `x` in a new scope by shadowing a local constant which is a higher scope.

`d` attempts to overwrite `x` in the same scope since guard does not create a new scope. In order for this to succeed, one would need the ability to universally overwrite symbols in a single scope which breaks a lot of the safety that Swift provides.

For example, this would have to be legal since it is overwriting both the type and value of a named constant just as example `d` does in the original post:

func d() {
    let x: Int? = 42
    let x = "42"
}

To me the biggest violation of intuition is the scope of a parameter: it seems to be available in the same places a local variable is (not uncommon in PLs), but one can shadow it with a `guard` as well.

Unfortunately, restricting this type of shadowing is probably too source-breaking. I also understand the tradeoff with allowing same-scope shadowing.

Has this bug been fixed in the meantime? func d() compiles and runs without problems with Xcode 12.5.1 and

Swift version 5.4.2.

Comment by Hristo Hristov (JIRA)

I also would like to know why local shadowing is compiling and working in current Xcode 12 and not working in another CI environment?

We do support this now apparently.