How are you liking it so far? (That’s the resource I am considering for getting started with SwiftUI)

Dope! Any hot takes from the lesson?

I stand with the trans community. Pass it along.

This took me forever to wrap my head around and it all boiled down to my lack of understanding of the Swift language.

The more you know!

Now here's an enum *without* associated value types.

Since there are no associated value types the compiler says we can compare instances of this Error type and slaps on the Equatable protocol at compile time.

As it turns out, in Swift, enums with no associated values get free Equatable synthesis!

Here is an enum *with* associated value types:

So what the heck was going on?

Somehow, the compiler is saying that RemoteFeedLoader.Error conforms to Equatable.

This led me to believe that the compiler was auto-synthesizing RemoteFeedLoader.Error's conformance to Equatable.

But what conditions need to be met in order for that to happen?

We could explicitly conform RemoteFeedLoader.Error to Equatable like so, but apparently we don't need to? 🤔

Here's the FeedLoader protocol's implementation class, RemoteFeedLoader.

No where in this code did we explicitly conform the Error type to Equatable:

On the surface it makes sense: LoadFeedResult is Equatable if the Error in the failure case is Equatable.

This means that the protocol's associatedtype Error need to conform to Equatable, which means that whatever class implements the protocol need to have an Equatable Error type.

If we uncomment the conditional conformance (the commented out line above), then the compiler error goes away 🫰, and we can compare LoadFeedResult types using XCTAssertEqual.

The puzzle 🧩:

Whenever I commented out the following line in the interface boundary, I would then get the accompanying compile-time error in the test code:

Day 6 of #100DaysOfCode

Log: github.com/webdavis/100...

Understanding the Swift compiler!

Last week I was struggling to understand how the Swift compiler was auto-synthesizing conformance to Equatable for an enum result type.

#code #swift #learning #compiler

No worries haha, still fun 👏

This is really interesting and reminds me how developers go from user stories to use cases. Seems every domain has its techniques for dialing in. Great stuff!

😆 I won’t be passing any Ophthalmology tests, but I enjoyed the UI! Great work!

1. What testing framework I should use.

2. If it’s is a class-per-test framework (e.g. the JUnit approach) or not.

3. If the language supports interfaces/protocols. If not, then what does it use to achieve composition?

Taking a break today—my sleep debt is piling up 😵‍💫 📈

However, I've found these posts really improve my understanding of things.

That being said, I want to get better at TDD. Currently, I don’t “think it” as well as I would like to, but these posts could help me change that.

Maybe that's the move.

This is some next level nerdom. Bravo 👏

Argghh!

I said all this and realized that I didn't make it very clear that I am referring specifically to the "try?" syntax.

You can see it in the first code snippet as follows:

let root = try? JSONDecoder().decode(Root.self, from: data)

(I'M TIRED lol)

Lolz 😂

Seems kinda convoluted! Also, now we have to force unwrap root.

Maybe that's why the Swift team implemented this.

(Side note: I usually hate reading documentation, but the Swift team actually does a really good job at it.)

(7/7)

(6/7)

Now let's see what it would be like to implement the same behavior without this syntax. We could convert this to a do-catch block, like so:

Here is what the Apple docs say about it:

"You use try? to handle an error by converting it to an optional value. If an error is thrown while evaluating the try? expression, the value of the expression is nil."

(5/7)

This is because Swift allows us to convert errors to optional values.

In this case we would rather throw our own domain-specific error. We don't care about the DecodingError thrown by decode().

So instead, if decode throws an error we instruct Swift to convert it to an optional value `nil`.

(4/7)

(3/7)

Take a look at the following static function. Why isn't there a do-catch block to catch the potential error that JSONDecoder().decode throws?

Converting an error to an optional value is a great way to handle situations where we want to throw a domain-specific error in favor of a third-party error that we don't control (e.g. DecodingError thrown by JSONDecoder().decode).

(2/7)

Day 5 of #100DaysOfCode

Learned about Swift.Error, including error handling in Swift, as well as generics.

Today I'll focus a specific case:

❌❓ Handling Errors by Converting them to Optional Values

Let's get to it!

(1/7)

Do you have any favorites from the freecodecamp podcast that you recommend?

Hey Zero,

Thanks for connecting! I followed you back 🥳

I totally get it—these topics are tricky for me too! That’s why I post about them; rubber ducking helps me process.

If something’s unclear, it might mean I haven’t explained it well. Feel free to ask or point it out! Let’s learn together 🙂