chore: Enable force_unwrapping for SwiftLint

[facumenzella]

Motivation

A couple of days ago I noticed #4794

Description

Enable force_unwrapping rule for SwiftLint. There's no reason to not have this enabled. It can always be disabled manually when needed. Better safe than sorry :)

[emerge-tools]

1 build decreased size

Name	Version	Download	Change	Install	Change	Approval
Paywalls com.revenuecat.PaywallsTester	1.0 (1)	11.2 MB	⬆️ 722 B	42.3 MB	⬇️ 494 B	N/A

Paywalls 1.0 (1)
com.revenuecat.PaywallsTester

⚖️ Compare build
📦 Install build
⏱️ Analyze build performance

Total install size change: ⬇️ 494 B
Total download size change: ⬆️ 722 B

Largest size changes

Item	Install Size Change
Other	⬇️ -494 B

View Treemap

---

🛸 Powered by Emerge Tools

[ajpallares]

Thanks for adding this! I agree that we should avoid force unwraps in general, so it's better to add the rule to the linter 👌

[JayShortway]

I'd like to offer a counter point: most of the diff in this PR is adding // swiftlint:disable force_unwrapping. Is this rule really necessary? Rules like this can add a lot of friction, and I'm wondering if it's worth it.

(I'm not blocking this PR, just wanted to share some food for thought.)

[tonidero]

Looks good! Regarding @JayShortway's point, IMO, I think this is a good rule to have, since we should normally avoid force-unwrapping. I think the comments right now are added so we minify the changes in the existing code, but we probably should address those as well. At least, enabling the rule would make us avoid force-unwrapping if possible in future code.

[JayShortway]

@tonidero Alright, yea makes sense. I don't feel as strongly about the rule (we're all aware that we should be careful when force unwrapping), but as I said it's not a blocker.

Seems that SwiftLint has a baseline feature, but it's not really documented. (To be clear, I'm not suggesting to add that. 🙂)

[facumenzella]

@JayShortway as @tonidero said, I think it's good to have, and it's good to disable it as well when needed.

Mainly because relying to code reviews to avoid potential crashes due to force unwraps is unnecessary IMO. If we disable it intentionally, it will also make the reviewer think twice to see if the disabling makes sense :)

I added a bunch of disables because I lack a lot of context in some parts of the code, but all in to remove them gradually.

---

I have no idea what baseline is, but it'll take a look

[JayShortway]

@facumenzella I can definitely agree to the better-safe-than-sorry mindset!

Regarding baseline, it's basically a file containing the current violations in the code, with the intent of fixing them later. It's a useful feature when introducing a new linter or rule. The new rule(s) will immediately apply for all future code going forward, while not requiring you to fix (or ignore) existing violations. Detekt and Android Lint have it too. For reference, here's our Detekt baseline in purchases-android.