I don’t like this crate either, it’s frustrating to use… but you don’t win any prizes for having a go at open source maintainers.
Create an alternative crate if you care enough, or pick a different crate to use. You can even literally pin to a previous version of this crate.
I have zero sympathy for folk coming along to a closed issue, which has been clearly closed and explained and trying to tell the maintainer they know better.
I have mixed feelings on this advice. On the one hand, it's not fair to criticize volunteer maintainers too harshly. On the other hand, the same person would probably see forking + marketing a fork as an attack—maybe not in the case of a small utility library, but certainly in the case of larger projects. A fork would be seen as an attempt to split or take over the community around the project because, well, that's exactly what it is. If you feel no sympathy for the users commenting on the issue you ought to feel not sympathy for the original maintainer in that scenario, and that seems like an unhealthy dynamic for open source as a whole. (For what it's worth I would feel no sympathy for maintainers that act like the one in this issue, but in general I would prefer people to spend some real effort on discussing and resolving disagreements before trying to fork anything important!)
Yeah you're right. I would never use this lib because I completely disagree with the maintainer in all regards here, from the coding choices to the motivations for doing what they did.
There's no point going to the issues tracker to tell him/her that though: just move on and pick a nicer library/maintainer.
There are two guardrails: 0. not being unprofessionally, unnecessarily critical 1. while delivering and receiving necessary constructive feedback about usability. It's a signal suggesting narcissistic tendencies without an ability to cooperate or grow, to be against listening to constructive feedback or complaining about the gift of feedback if it wasn't delivered in precisely your perfectly arranged, expected format and process others aren't aware of.
People forget that base64 has variant _all the time_, that leads to bugs.
So deprecating `decode` made sense.
But then what do you do instead?
a `decode_**` for each standard variant ... not really nice design
a `decode2(data, standard)` better but if you anyway need to import the standard and one additional thing, that thing could be a trait instead of a method and the `2` in the name is quite confusing
a braking change? definitely not worth it
a `prelude` module which exports the engine trait and reexports like `BASE64_STANDARD`? Well he did that.
Because you are now encoding parameter choices in function names instead of making them parameters.
I mean it's not terrible design.
But having to do a `use base64::prelude::{Engine, BASE64_STANDARD}` is also not terrible design.
Nor is `use base64::engine::{Engine, general_purpose::STANDARD as BASE64}`, through it's less nice.
So given that there is already and equally good design there anyway, there is no reason to add additional code, especially if that code would make it easier to make a mistake when using it.
I guess if this would be designed now from scratch it would have something like a `decode(data, standard)` function, but `decode` is already in used (even through deprecated) so we can't have that.
Create an alternative crate if you care enough, or pick a different crate to use. You can even literally pin to a previous version of this crate.
I have zero sympathy for folk coming along to a closed issue, which has been clearly closed and explained and trying to tell the maintainer they know better.