Concatenate a OIDs

[zotho]

Just draft to implement possibility of #44

const A: Oid = oid!(1.2.3);
const B: Oid = oid_append!(A, 4.5); // 1.2.3.4.5
const C: Oid = oid_append!(A, B);   // 1.2.3.1.2.3.4.5

But this functionality requires #![feature(const_precise_live_drops)]

[lilyball]

How much of a change would it be to change Oid so instead of exposing a single slice of bytes, it exposed an iterator of byte slices instead? This way an Oid could have an optional base_oid field. Serializing and equality comparisons would use the iterator. This would be a breaking change of course, as we'd be removing the byte slice view, but it allows for trivial compile-time and runtime appending. The biggest issue I can see (beyond it being a breaking change) is that ideally you'd want to only allow appending of relative Oids to a base, but this isn't expressed in the type system, so you'd have to define some reasonable behavior for what happens if you append an absolute Oid to another one (the obvious behavior is to treat the absolute one as a relative one instead, which just expands its encoding by one byte, and means oid!(1.2.3) + oid!(4.5.6) doesn't punish me for forgetting the rel keyword).

[chifflier]

So, the concatenation is done using a mix of const fn and macros. Is it entirely resolved at compile time ?

Otherwise, another approach would be to entirely do that at runtime, and use the .bytes() method from oid, so it would work generically. The caller would probably have use something like lazy_static.

[chifflier]

Unfortunately, this prevents from building with stable rustc, which would not be acceptable.
Why is it required ? I see no code using it (at least in rustc 1.53, bytes_from_borrowed does not require it)

[chifflier]

I don't know what the best behavior is:

• returning an empty slice hides the error, which may be bad
• this is a const fn, so we can't panic (an ugly way to do that would be to do something like {"error message"[256]; &[]} so at least we get an error message

[chifflier]

I really would prefer not to do this (see below)