Constructing `OAuthBearerError` is not (directly) possible

[TheJonny]

If I understand it correctly, an instance of OAuthBearerError should be created in an implementation of SessionCallback when using the OAUTHBEARER mechanism.

But this struct is marked #[non_exhaustive] (preventing direct initialization) and has now new function.

The only constructor I found is deserialization, which can be used as a workaround.

I suggest to remove the #[non_exhaustive] annotation, as https://datatracker.ietf.org/doc/html/rfc7628#section-3.2.2 does not mention the possibility of additional members.

[dequbed]

If I understand it correctly, an instance of OAuthBearerError should be created in an implementation of SessionCallback when using the OAUTHBEARER mechanism.

But this struct is marked #[non_exhaustive] (preventing direct initialization) and has now new function.

You're absolutely correct, this is a type consumers of rsasl are supposed to create and return. ^^'

I suggest to remove the #[non_exhaustive] annotation, as https://datatracker.ietf.org/doc/html/rfc7628#section-3.2.2 does not mention the possibility of additional members.

Hmm, I'm not convinced this is a good move, since a future RFC may extend the returned struct. I'm not well versed in OAuth so I can't tell if that is likely, but I'd like to be able to still use that struct in that case. I will add a const fn new instead, it has no overhead compared to direct struct initialization but it allows me to extend the struct in the future.

[TheJonny]

Thank You for the quick reply!

The only overhead using a new function would be a syntactic one, but you are right, a const fn new(status: &str) does not hurt and is more correct than a Default implementation

[dequbed]

I cut a new release 2.2.0 that includes a fix for this issue. Feel free to re-open this issue if it didn't :)