Episode 7: The provided code is not really composable about episode-code-samples

[timojaask]

That makes sense @stephencelis -- thanks so much for explaining your thinking about this. I see how this is more of an introduction to the concept before diving into applying it to structs.

I'll close this issue now.

Love the series! ❤️

[stephencelis]

Hi @timojaask!

I might misunderstand the meaning of "very composable", but it seems that this code is not very composable.

When we use the word "composition" what we mean is the ability to take 2 things and combine them into a 3rd thing. We consider things "more composable" when there's less ad hoc work required to do such combining. The reason why we consider functions "super composable" is that we can reach for things like <<< and <> to do the combining of existing functions, and we can decompose functions into smaller and smaller units that can be glued back together. So in this case, by modeling setters as functions, we can break them into smaller setters and glue them back together as we would with any function. Without these operations you'd need to do more ad-hoc work to combine mutations together. Does that make sense?

This only works if you touch all three elements of the nested tuple. What if you want a transformation that only updates one or two of the tuple's elements? The compiler will fail to infer the type for the remaining element(s).

You have to give the compiler a hint, for sure. Swift has a Generics Manifesto that details how this may improve over time, though, if "generic" variables ever become a thing.

This seems to contradict "very composable" and "easy to reuse code".

The tuple example is a bit of a toy that is definitely complicated by Swift generics, but the examples in the next episode are a bit less fussy, since they use key paths with more concrete types.

Does that all make sense?