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.
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.