[Let's consider guard as it has more strict requirements, and a potential new syntax working for guard would work for all the other cases]
In terms of teaching Swift and progressive disclosure, a potential learner should initially consider that what we're doing here is matching an Optional instance to a pattern, and binding a value to a new instance:
let optionalValue: Int? = 42
guard case .some(let value) = optionalValue else {
return
}
print(value)
As a next step, the learner would consider the shorthand syntax for matching Optional as sugar for the previous form:
let optionalValue: Int? = 42
guard case let value? = optionalValue else {
return
}
print(value)
Finally, the even shorter one for some specific cases of pattern matching (like guard):
let optionalValue: Int? = 42
guard let value = optionalValue else {
return
}
print(value)
This makes a lot of sense, it takes into account every possible combination of Optional-returning expressions, var vs let, et cetera, and would be pretty conclusive to me.
The unfortunate reality is that it's often the case that the Optional instance will already be called value, or something the doesn't include optional in the name, which makes sense because the optionality is in the type (we call instances let name: String, not let nameString: String). Also optional in the instance name is pretty heavy, and usually undesirable, except for very specific cases. Thus, it seems to me that the "real" problem here is that we tend to assign the same exact name to the original Optional instance and the newly bound non-Optional one.
But if the learner is at the point of clearly and intuitively understanding the final shorthand syntax, the fact that they're going to write and read something like guard let value = value is only a concern insofar that it "feels a little strange" (not really, actually, after a few years of writing stuff like that). Thus I've learned to try and add some hint to the Optional instance name, in order to distinguish it from a potential non-Optional one (for example, using optValue).
I agree that this "feels" strange and I don't have a solution for this, but in my opinion possible solutions should not undermine some of the core foundations of Swift, and should not obfuscate the fact that we are actually doing an assignment to a new, completely different constant.
This suggests some new kind of keyword, operator or declaration, that could maintain the assignment part intact, and produce a shorthand syntax that better conveys the intent. Circling back to guard case .some(let value) = optionalValue, I'd suggest that the guard let value part should be maintained. I can think of a few options:
guard let value =? else { return }
guard let value = unwrapped else { return }
guard let value unwrapped else { return }
guard let value? else { return }
guard case let value? else { return }
guard unwrap let value else { return }
I'm not sure if any of those is good. I probably prefer the last one guard unwrap let value else { return } where unwrap is a new keyword that replaces case in cases where the pattern that we're matching to is assignment from an unwrapped Optional.
Also guard case let value? else { return } make sense to me because what we're logically doing is using the intermediate form guard case let value? = optionalValue else { return } but omitting the = optionalValue part because the name of the instance is the same: this feels consistent and rational, because it uses already existing syntax and omits a redundant element.