This is a quality-of-life improvement, as it may save lots of typing in
the common case (see the diff in parsers).

This will come in handy when we implement the ability to extract
data from nested children.

This was an oversight. Even though we apparently don't have tests for
this anywhere, it is what the old functional macros do.

This text codec was previously implemented only for Option<String>, this
extends it to all types implementing those two traits, such as numbers
or JIDs.

These more closely mirror how enums work currently with the macros.
Non-exhaustive enums may be useful though and kind of were the natural
thing to implement.

Previously, if you put `codec = FixedHex<20>.filtered(..)`, it would
cause a confusing "expected `,`" message at the place of the `.`. This
code adds a helpful "try adding a `::` before the `<`" message pointing
at the `<` in the type path.

We can do this because we know that `x < y` cannot create a
`TextCodec<T>` for any `T`. This is because `<` is guaranteed to return
a boolean value, and we simply don't implement `TextCodec<T>` on bool.

This allows stateful or configurable codecs without having to express
all configuration in the type name itself. For example, we could have a
Base64 type with configurable Base64 engines without having to duplicate
the Base64 type itself.

(Note that the different engines in the Base64 crate are values, not
types.)

See inline comments for the rationale.

Can you see it coming?

By removing that, the lint won't trigger for identifiers with trailing
underscores (which become then embedded underscores which normally trips
the `non_camel_case_types` lint).

Users can now rename the generated types altogether, which means that we
do not need this anymore to avoid lints.

In 1265f4b, we introduced a change which may cause a conflict of type
names when deriving the traits on two different types. While a
workaround existed (use `mod`s to isolate the implementation), that is
ugly.

This commit allows overriding the choice of type names.

The Tune::new() constructor wasn’t pub before that.

Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>

Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>

Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>

Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>

This allows building recursive tree structures.

How would you learn about them otherwise? This is particularly important
for the derive macros (behind the `derive` feature flag).

Fixes #133.

This introduces support for `Cow<'_, [u8]>` (which is not needed
currently, but still good to have) and generalizes the `Option<T>`
implementation so that it doesn't have to be copied for every other type
supported to be Base64'd (we may add support for `bytes::Bytes` at some
point, for instance).

Now it's not limited to a single feature gate per type (or even just
feature gates: it should now also be possible to add constraints
based on OS, for example) anymore.