What's keeping this from being 1.0 right now?

[Lokathor]

This API is the exact API that I was imagining when I went to look for a crate like this. More generic even, which is cool.

The version is only at 0.2, but it's been sitting there for half a year it looks like. Is there something holding it back from being 1.0 or could it be version bumped?

[sdroege]

Nothing is really preventing this from being 1.0 apart from some wider usage to see if there are any deficiencies with the current API.

In what context are you using it? :)

[Lokathor]

I know a guy who uses it on switch to write driver type code. File system parsing sort of stuff.

[sdroege]

Does it currently prevent anybody from using this crate because it's not 1.0 yet?

Updating the version number for no reason would mean that everybody has to update their Cargo.toml.

[Lokathor]

1. it's a moral difference, I'll admit. It shows a confidence that the package can be used for serious purposes without creeping dangers.

2. no one would have to update anything if they didn't want to. The current version doesn't go away even if a 1.0 version comes out.

[sdroege]

1. it's a moral difference, I'll admit. It shows a confidence that the package can be used for serious purposes without creeping dangers.

I never really got this obsession with numbers people seem to have. There's enough crap out there that is versioned 1.0 or even higher, and enough great stuff that has lower version numbers. In the end you always have to look at the dependency yourself, everybody has a different understand of what "1.0-quality" means.

When I do the next update I'll update the version to 1.0.

2\. no one would have to update anything if they didn't want to. The current version doesn't go away even if a 1.0 version comes out.

And then you potentially have multiple versions in your dependency tree, which seems more ugly than cosmetics about version numbers.

[roblabla]

Having multiple version in the deptree doesn't really seem that ugly? The semver trick can (and should) be used to avoid type fragmentation this might cause.

1.0.0 is mostly a stability promise. Semver defines 1.0.0 as the first release of the public API. https://semver.org/#spec-item-5. Before this version, all bets are up and breaking changes are allowed.

The idea is that, after 1.0.0, the public API is stable and breaking changes are very unlikely to happen. This isn't something I'm making up, it's in the semver spec, and is the primary motivator behind the big push to 1.0.0 that the Rust Team championed. Of course, there is a bunch of shit crates out there that are published 1.x. That's besides the point though. It's a way of communicating the author's intention, not a way to verify a crate's quality :).

[sdroege]

#3 and #4 implemented some API changes since last time this issue got comments.

If there's no new API change coming up in the next 2-3 months, I'll consider releasing the current API as 1.0.

[dignifiedquire]

Just found this crate, does exactly what I needed, API matched very well the usages 👍 thank you

[sdroege]

Currently my main worry is that the Vec transformation is actually unsound: it causes memory to be freed with a different alignment requirement than it was allocated with, which I think is not allowed. I'm not aware of any allocator breaking from this but that might of course change in the future.

[Lokathor]

Ah, I didn't notice the Vec cast (or maybe it wasn't there 1.5 years ago).

Yeah that is unsound.

[sdroege]

I guess let's get rid of it then and release everything else as 1.0. Too bad, it's quite useful.

[Lokathor]

Bytemuck has a vec cast that checks alignment, which is sound.

[sdroege]

This here also checks alignment, that's not the problem. The problem is this, coming from AllocRef::dealloc():

Deallocates the memory referenced by ptr.
Safety

• ptr must denote a block of memory currently allocated via this allocator, and
• layout must fit that block of memory.

Memory fitting
[...]

• The block must be allocated with the same alignment as layout.align(), and

This means that you can't drop a Vec<u16> (allocated as such) safely as a Vec<u8>. While the alignment is compatible in this direction, it is not the same.

Casting &Vec<u16> to e.g. &[u8] OTOH is fine.

[Lokathor]

yeah just make the alignment check only allow equal alignment ;P

[sdroege]

That seems not very useful :) Sure, you can go from u32 to f32 and u64 to f64 and back but otherwise...?

[sdroege]

See #15