Comments (16)
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 :).
from byte-slice-cast.
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? :)
from byte-slice-cast.
I know a guy who uses it on switch to write driver type code. File system parsing sort of stuff.
from byte-slice-cast.
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
.
from byte-slice-cast.
-
it's a moral difference, I'll admit. It shows a confidence that the package can be used for serious purposes without creeping dangers.
-
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.
from byte-slice-cast.
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.
from byte-slice-cast.
#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.
from byte-slice-cast.
Just found this crate, does exactly what I needed, API matched very well the usages 👍 thank you
from byte-slice-cast.
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.
from byte-slice-cast.
Ah, I didn't notice the Vec cast (or maybe it wasn't there 1.5 years ago).
Yeah that is unsound.
from byte-slice-cast.
I guess let's get rid of it then and release everything else as 1.0. Too bad, it's quite useful.
from byte-slice-cast.
Bytemuck has a vec cast that checks alignment, which is sound.
from byte-slice-cast.
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.
from byte-slice-cast.
yeah just make the alignment check only allow equal alignment ;P
from byte-slice-cast.
That seems not very useful :) Sure, you can go from u32
to f32
and u64
to f64
and back but otherwise...?
from byte-slice-cast.
See #15
from byte-slice-cast.
Related Issues (8)
- Support conversion between Box<[u8]>/`Box<[f32]>` (and similarly for Vec) HOT 12
- Cannot compile on wasm32-unknown-emscripten target (debug mode) HOT 3
- Tuple support HOT 5
- Support primitive array HOT 1
- Please add support for manually selecting endianness HOT 2
- Zero length slice casting HOT 3
- Add support for casting Vec<T> -> Vec<U> HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from byte-slice-cast.