The rule for IUOs is "try to treat them as Optional before trying to unwrap", but I agree that the diagnostic doesn't make sense here. Still, you can work around it with an explicit ! or as.

cc @xedin

It looks like when IUO was made an attribute of the decl, we didn't fix all of the places to check for that attribute...

Do you want to take a look at this one, @theblixguy?

Sure. Do we not want to emit this diagnostic if we're implicitly unwrapping to Any?

@theblixguy No, we should keep that, but before emitting such diagnostic we should check if that optional type is actually optional and not IUO.

Hmm, seems like it's not possible to use `OptionalTypeKind` for this. Probably need to check the type repr.

@theblixguy Since the attribute is attached to declaration you'd have to get declaration for optional and go from there similar to https://github.com/apple/swift/blob/master/lib/Sema/ConstraintSystem.cpp#L2116

Hmm something like this doesn't work:

if (srcType->getOptionalObjectType()) {
  auto decl = srcType->getEnumOrBoundGenericEnum();
  if (decl->getAttrs().hasAttribute<ImplicitlyUnwrappedOptionalAttr>()) {
      return;
  }
}

I do get the declaration for optional, but it doesn't have that attribute.

Maybe what we need to do is

if (srcType->getOptionalObjectType() && hasImplicitlyUnwrappedResult(subExpr)) { 
  return;
} 

I'd expect that attribute to be associated with declaration of the entity IOU type is associated with e.g. property in this case, instead of Optional itself (which is what you are checking). I would be great if we could extract that warning from MiscDiagnostic and use a fix to diagnose it, it could be done in matchTypes.

Sounds good, I have a fix ready for it, just trying to figure out why it's not diagnosing (even after passing `warning=true` to ConstraintFix). Maybe the fix is being ignored somehow by matchTypes().

Nevermind, I fixed it. I'll create a PR now

PR: #23617

Can you cherry-pick this to 5.1 when you and Pavel are done with it?

Sure!

After a lot of discussion, we've decided to update the diagnostic to make the behaviour clearer, instead of removing the diagnostic completely. This is now resolved on master by PR #23617 and cherry-picked to the swift-5.1 branch as well.

Comment by Veda Murthy (JIRA)

Given that the warnings will still be there, can I get some advice on what you think I should do in my example code?

Options:

1. Make no code change and leave the warning, but then I'll have hundreds of ignored warnings in my project and won't be able to find real warnings among them.

2. Change views.append(shutterButton) to views.append(shutterButton, but then if someone later changes the definition of shutterButton to UIButton? instead of UIButton), a bug could get introduced here.

3. Wrap every reference to shutterButton in an "if let" block. I guess this is the most correct but then what benefit did I get from defining it as a UIButton! instead of a UIButton?

I would really appreciate your perspective on this. Thanks!

I would suggest reading https://swift.org/blog/iuo/.

1) You could do that, but it depends on how many warnings there are and whether you want these warnings to persist.
2) `UIButton?` and `UIButton!` are basically the same, except that the latter is unwrapped automatically when needed. So, I don't think switching to `UIButton?` would create a bug.
3) Even if you defined it as `UIButton?`, it would trigger the same warning.