Brendan Lensink

> I don't think we should merge this to master. That's totally reasonable, would this end up being version 0.7.2 then? > I think we can allow specifying name and...

@sakuraehikaru Is it worth keeping this PR open, or can we close this and re-open if we want to address this in the future?

To be clear, we currently _don't_ have any support for network reachability built into Netable, and this issue is proposing that we evaluate if we feel like we should add...

@nbrooke does this seem reasonable to you? Any gotchas or other features that might be nice to have?

> I assume in that sample signature above that "Request" return value should actually be a URLRequest, right Oops, fixed > I think Ideally they should be non-overlapping (i.e. no...

This is interesting, but AFAICT would only be available in iOS 15.4 and above. This is a little tricky, since I think it's unlikely any kind of backwards compatible solution...

It's been my experience with past projects, that we usually run into a situation where we've got a giant `Manager` or `Model` class full of thin wrappers on `netable.request` due...

@JeremyChiang do you have a sense of how exactly we'd go about implementing this? What error classifications would we use? Just `isNetworkingError: Bool`? Or do you think there might be...

> Is testability the main reason we sill need to create thin wrappers? IMO yes, the biggest responsibility for repos right now in my mind (other than passing data between...

I'm pretty strongly opposed to adding more completion blocks to `request` unless there's a good reason. I had assumed this was more like adding some sort of classification to `NetableError`s...