Repository navigation
Why is MVector's constructor exposed? #517
Description
Activity
It is unsafe, very unsafe. If you put wrong numbers there program may dance happy little jig all over the heap and then segfault horribly.
If you look at mutable storable and primitive vectors they expose constructors too. And it was like this since earliest versions. I think this was done in order to give immutable vectors access to internals of mutable ones. This is not particularly good reason but vector does poor job in separating safe and unsafe API
OK, if the only reason is so that other modules can use the constructors then perhaps we can firstly place a big warning message next to them, and secondly, move them to a
.Internalor.Unsafemodule.Documentation improvements are always welcome.
Moving constructors would be a breaking change and quite a bit of work. On top of it it's not that big improvement over current "just don't touch it and everything will be OK". It seems there's no one willing to do design and implementation work
The constructor of
MVectoris exposed:This seems pretty odd, because the two
Ints are the offset into the underlyingMutableArraythat theMVectorstarts, and the length of theMVector. both of which are used for bounds checking before deferring toreadArrayof aMutableArrayviabasicUnsafeRead.So I'm confused. Firstly, can changing those fields not lead to segfaults? And secondly, doesn't changing those fields have no real purpose, since there are better ways of obtaining the ends one wants via the safe API (or even the unsafe one, with functions explicitly named as "
unsafe" if one really wants the performance)?Or have I missed something, and there is a good reason for exposing those fields?