Consider moving `impl_bytelike_traits` macro to `internals` about rust-bitcoin

[Kixunil]

Another question is if it should be used in secp256k1, a crate with general-purpose name. I was thinking that over time we could extract useful concepts from internals to separate stable crates. This would also resolve some of our issues (e.g. making InputString public). Having a crate for byte-like newtypes sounds quite appealing to me.

[apoelstra]

Having a crate for byte-like newtypes sounds quite appealing to me.

Agreed, though there's a bit of non-overlapping ad-hoc weirdness in both hashes and secp256k1 which would want this. (hashes has the weird byte-reversal stuff and secp256k1 has the "don't Debug-output secrets" stuff).

I've also started to dislike calling macros from one crate to generate code in another crate... the API-breakage issues are so subtle and difficult to detect, on top of macro code being so hard to read.

I wonder though, if we wrote it as a module that lived in its own repo, and we subtreed copies into both crates...then the macros would never be in anything's public API and we wouldn't have to worry so hard about breakage.

[Kixunil]

I think the reversal in hashes is small and harmless enough that it doesn't really matter and we could solve the secp256k1 thing by having an option to not impl Debug and Display (which we might want anyway to reduce dependencies).

the API-breakage issues are so subtle and difficult to detect, on top of macro code being so hard to read.

Yes, they are. But I think they're kinda similar if you do it within a crate. The only workable solutions I can think of are "write it well the first time and then do not touch" and "have all our known dependencies in CI" (AKA crater).

I wonder though, if we wrote it as a module that lived in its own repo, and we subtreed copies into both crates...then the macros would never be in anything's public API and we wouldn't have to worry so hard about breakage.

The only problem this appears to solve is limit the damage of accidental change to the few crates that subtree it. I'm not really convinced that's worth it.

[apoelstra]

Ok, yeah, that all sounds reasonable.

Then as a secondary question, should this really be its own crate or should it be part of hex-conservative? Because you basically always want byte-slices to be representable as hex.

[Kixunil]

There were requests to not depend on hex-conservative from hashes, one of the reasons being that seeing hex-conservative as base58ck dependency (just because of the sha256 algo) looks stupid. Therefore it should be a separate crate.

[apoelstra]

Yeah, that's a good point. Though I guess hex-conservative should be an optional dep of the byte-wrapper crate.

[Kixunil]

Yes, it should.

[tcharding]

Mad, this is the crate that we should be able to stabalize first!

[Kixunil]

Oh, we can't stabilize it until we stabilize hex or figure out what to do about FromStr.

We could also just not provide FromStr at this point, implementing it manually in unstable crates for now (or using a different macro).

[apoelstra]

Oh, we can't stabilize it until we stabilize hex or figure out what to do about FromStr.

I believe implementing it later would be a breaking change.

My preference is to just stabilize hex -- which we haven't touched in months and have no open feature requests for -- but my second preference would be to wrap the hex errors so we can move on.

[Kixunil]

I believe implementing it later would be a breaking change.

Adding it to the macro to work would be but not if we create a new macro instead.

We could also have an attribute to opt-out from it and force its usage at the beginning then remove the restriction.