# \`if let\` shorthand **URL:** \ **Category:** Pitches\ **Created:** [December 22, 2021, 10:23pm UTC](https://forums.swift.org/t/if-let-shorthand/54230 "2021-12-22T22:23:36Z")\ **Posts on this page:** 1\ **Showing post:** 188
**Author:** ![ben-cohen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ben-cohen/32/296_2.png) [@ben-cohen](https://forums.swift.org/u/ben-cohen)\ **Post date:** [January 2, 2022, 4:52pm UTC](https://forums.swift.org/t/if-let-shorthand/54230/188 "2022-01-02T16:52:01Z")
> [@Chris\_Lattner3](#): > > Like some others on this thread, you are stating your opinions as though they are facts without justifying them or acknowledging other people's perspectives and the truth behind them Mostly, people caveat some of their opinions with "I think" or "It seems". I do so liberally in this thread. But it becomes very tedious to read if you do it constantly in every sentence (even with abbreviations like "IMO"), so sometimes a statement is left bare. When this happens, it is best not to latch on to it and complain that this particular thing has been stated "as fact". It is clearly someone's opinion when viewed in context. For example: > [@Chris\_Lattner3](#): > > This wouldn't be an "inout" binding to the element with the optional, which would betray a lot of expectations and introduce a lot of bugs. No caveat here – you seem to be stating it will cause a lot of bugs as a fact. But of course you aren't – everyone understands that this is just your opinion. But the words used here are extreme. It **will** introduce **a lot of bugs**? The `var` in `if var x` is "nearly invisible"? This is clearly hyperbole (IMO of course) and I think the discussion would be better without extreme characterizations like this. What (I think!) you mean is that you can envision a hypothetical scenario in which someone _might_ think it's an inout binding and that this _could_ lead to a bug occasionally. And I in turn think that this is not going to be a problem in practice. Nowhere else in the language does `var` do this, including the very similar `if var x = x` that already exists. And current use of that feature does not suggest this problem is causing "a lot of bugs" as far as I know. This is a phenomenon we get a lot on these forums, which I call "performative misunderstanding", where a possible but frankly implausible misinterpretation is cited as a reason not to adopt a feature. I think it's a real problem, because it worsens good proposals, for example giving us waffly names for standard library functions. It can cause us to skew the design towards the very first use of a feature, not the subsequent 1,000+ uses, all the while not actually making that first use particularly better. > [@Chris\_Lattner3](#): > > How would you defend rushing a decision about this when ownership is close at hand? I wouldn't. I'm not suggesting we accept a proposal without considering how the future direction of borrows and moves might interact with it – though I do think you're overestimating the closeness of the design of type-system-level moves and also the likelihood it will affect this particular sugar. What said in the text you quote is that to keep this discussion on track and hopefully converge on a proposal we _could_ run is that we first discuss the language as it is today, and _then_ once settled on a good potential addition, we think about its interaction with future syntax for borrows. I also think there is a flip side to the "we've done without this for 7 years"... which is that we should be a bit sheepish about that. It's not great that this clear pain point has gone unaddressed so long, and putting it off another two years because it _might_ not quite fit with a feature that hasn't really been designed or pitched yet is not OK. What we will probably need to do is make a judgement call about the likelihood of future directions clashing, maybe with some early sketches of what that feature might look like. But that is going to be a long and probably pretty hand-wavy discussion, and I think it's best had after we handle the already hard-enough task of settling on a proposal that works for the Swift of today. --- _[View the full topic](https://forums.swift.org/t/if-let-shorthand/54230)._