Is there a reason ParsingError isn't public?

[sbeitzel]

I'm working on a project that can accept input as either a file or as input on STDIN, and I'm encountering some frustrating problems parsing the inputs. I'm sure it has to do with newlines, but it's getting frustrating to keep trying to add them in some cases and see what happens, then remove them and see what happens, &c. It's tiresome. Now, the parser is definitely throwing a ParsingError. My parse call is alone in a do block and the catch looks like:

        } catch {
            print("Error parsing input: \(error.localizedDescription)")
        }

...and sure enough, the console output looks like:

Error parsing input: The operation couldn’t be completed. (Parsing.ParsingError error 0.)

I'd like to drill down into that error, but because ParsingError isn't public in swift-parsing version 0.13.0, I can't get specific on my catch block like:

  } catch Parsing.ParsingError {
    print("Parsing error: \(error.debugDescription)")
  } catch {
    print("Some weird error: \(error.localizedDescription)"
  }

[stephencelis]

@sbeitzel The main reason it's not public is because we don't feel the API is ready yet. While it's much much better than not having errors at all, we still have some things to learn and want some license to change things in the future.

That said, we don't want to prevent folks from working with the library as you want to, so maybe we should put ParsingError under a public @_spi(Errors)? We probably won't have time to do this right away, but if you are up to PR this change, I think we'd happily take a look and merge things.

[sbeitzel]

Sure, I'd be happy to take a swing at that.

[sbeitzel]

Okay, so marking something @_spi(Errors) has to come along with marking that thing public (otherwise it's not available outside the module anyway). That, in turn, means that the thing being marked can't be @usableFromInline. And, because the thing I'm marking is an error type, that ultimately means that any code that can throw the error can't be @inlinable and that will mess up all the sweet, sweet optimization work done in the library (okay, not all, but still).

So let's not do that.

Instead, I'll change my catch block:

        } catch {
            let description = String(reflecting: error)
            print("Error parsing input: \(description)")
        }

[stephencelis]

That works, but also if @_spi causes too many problems, we're also open to underscoring the API for now: _ParsingError. Brandon and I will chat about that soon!

[sbeitzel]

I think what I ran into is that so much of the library is tagged with @inlinable and @usableFromInline. When I marked ParsingError as public, Xcode started complaining about various uses of the error type. The way I understand what @inlinable means, I'd wind up having to change a lot more of the library's surface than just publishing the error type, and I've not thought hard or long enough about it to want to go down that road.

Meanwhile, if a consumer of the library can actually attach a debugger and step into the catch block, then they could interactively look at the error's information. The only real need for a change is when, like me, one couldn't easily run the code in a debugger, and that feels like a really edge case. Changing the way the error gets printed out gave me enough information to move forward.

Now, it's possible that someone might want to specialize the catch blocks based on other errors that could pop up, but as the library exists right now, the only error type that can show up is a ParsingError, even if that is a non-public type. So, as you say, you'll probably want to have a more thoughtful chat about it. I don't know that there's any call to go rushing something out, though.

[stephencelis]

@sbeitzel Were those error more related to the @_spi annotation, though? I believe simple public types are inlinable, so:

-struct ParsingError: Error {
+public struct _ParsingError: Error {

If this does work without the trouble you were encountering, we'd be down to merge a PR, but if it's not an issue for you and doesn't help after all, no worries and no need to spend the time 😄