feat: implement AsRef<[u8]> for Atom

[dislogical]

Also adds disambiguating functions as_str() and as_bytes() to mirror std apis

[mrobinson]

Seems fine to me except that the tests are failing to compile, which probabaly indicates API breakage.

[dislogical]

Ah shoot, I tested integration-tests but must have missed the built-in tests. I'll fix and push when I'm back in front of a computer.

And yes, technically this is a breaking change as direct calls to as_ref() will now be ambiguous. If this is a deal-breaker I'm happy to take the L and close this.

[mrobinson]

And yes, technically this is a breaking change as direct calls to as_ref() will now be ambiguous. If this is a deal-breaker I'm happy to take the L and close this.

I think this isn't a problem in-and-of itself, but will require us to do a minor version bump. @SimonSapin Do you mind also taking a look at this one?

[SimonSapin]

It should all optimize away but I’d prefer going through fewer layers of abstraction. The actual logic is in the Deref impl so, here and in the new as_bytes method let’s use this:

Suggested change

	pub fn as_str(&self) -> &str {
	AsRef::as_ref(self)
	}
	pub fn as_str(&self) -> &str {
	self // auto-deref
	}

[dislogical]

Good catch! I'm actually just going to implement all of the logic in as_str as as_bytes, and then the traits can call into these. I think that'll make the code much easier to follow.

[SimonSapin]

Suggested change

	pub fn as_bytes(&self) -> &[u8] {
	AsRef::as_ref(self)
	}
	pub fn as_bytes(&self) -> &[u8] {
	str::as_bytes(self)
	}

[dislogical]

Note that per semver spec, since the major version of this crate is currently 0, you don't need to bump to version 1 as anything is allow to break at any time. That said, I get that a) that can be annoying for down-stream users, and b) this crate seems pretty stable so a 1.0 may be worthwhile anyway.

[nicoburns]

This crate has public dependency on phf (which is not 1.0). So it might be a bit premature to make it 1.0

[SimonSapin]

since the major version of this crate is currently 0 […] anything is allow to break at any time

That’s what semver.org says but not what cargo does. For example if a Cargo.toml specifies [dependencies] string_cache = "0.8.3", Cargo reads this as >= 0.8.3, < 0.9.0 and may select version 0.8.9 since it’s the latest that it considers compatible: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#version-requirement-syntax

I think this isn't a problem in-and-of itself, but will require us to do a minor version bump.

@mrobinson I assume you meant an incompatible bump from 0.10.0 to 0.11.0, as opposed to 0.10.1?

[mrobinson]

@mrobinson I assume you meant an incompatible bump from 0.10.0 to 0.11.0, as opposed to 0.10.1?

Yep, I meant a bump to the next minor version in the (major, minor, micro) triple.