-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate unsafe functions into their own Unsafe modules #361
Comments
|
My experience with Changes of such magnitude deserve a wider community discussion and CLC involvement. I suggest sending to libraries mail list an RFC with a disclaimer "Discussion is taking place in vector issue tracker, replies to this email are not necessarily monitored by maintaners". |
I also try to avoid breaking changes as much as I can, but this ones in my opinion are justified. I totally support as wide discussion on this issue as possible, so naturally CLC and libraries list are a must. I personally prefer to stay away from writing emails whenever I can, so maybe one of you @Shimuuar or @Bodigrim could kick off this discussion on the appropriate channels? it would be awesome if you could 😉 Ok, so a proposed high level timeline:
The most important question right now we need to answer is: Will this restructure happen or not? If the answer is no, then we can close the ticket and get on with our lives. On the other hand if the answer is yes, then we can slowly work out the gory details over time, because the first stage is additive and non-breaking so there is really no rush on this. However, there is nothing wrong with discussing those gory details now. Who knows, someone might come up with real blockers. |
I compiled list of unsafe API for mutable vector so we can understand what we're getting into. And we have quite a bit of unsafe APIs. I didn't include Pure vectors
Mutable vectorsUnsafe = "not memory safe"
Unsafe = "doesn't zero-out memory"
Constructors
DiscussionWe have a lot of unsafe APIs. I think it makes perfect sense to move most of them into Unsafe modules. We'll still need to export Vector/MVector type classes and functions for working with pointers for storable vectors. |
I do not feel motivated enough. Not that I doubt technical merits of separating safe from unsafe, but given my experience with I'm fine with either exposing constructors from existing modules, or not exposing them at all (I'm happy to |
@Shimuuar thank you for compiling this list, it's very helpful. @Bodigrim breakage is ok, but only if it is worth it, if in the end we will have a better and safer API. Let me give it a try and give you some motivation. Recently I was digging through older versions of vector and noticed that vector-0.9.x had Considering that this is a recurring proposal, I do think it is worth doing it. Also, it is the right thing to do. @Bodigrim if you personally don't feel motivated to do the work, that's totally fine, no one will be asking you to do anything about it. But if you believe that the proposal is actually the wrong thing to do, then can you please elaborate on why. Core packages like bytestring, random, vector, text, etc. serve as examples of how APIs should be designed in Haskell. It only makes sense that they actually live up to their name of core packages an provide a worthy example. @Bodigrim I realize that you got some push back on changes you made in new version of PS. Honestly, I am more scared about breaking changes that adjust semantics of existing functions (like the issue we discussing about maximumBy #362) vs changes that result in a compile error. |
As a random user, I'm completely happy about having Safe modules, whether it is the current modules or it gets the name |
@gksato I don't think we'll be able to mark @lehins I agree that this restructuring has technical merits. But it is not clear to me that it is worth breaking every other package: things like |
@Bodigrim I know. Sorry, I just want them to be |
@Bodigrim, as @gksato pointed out all of the safe modules would have to be marked
The initial change would not introduce any breakage at all, so that is not that scary, but further down the road it would require a little bit of work in order to fix compatibility, but the change is minimal: namely adding a new import whenever unsafe functions are being used.
No doubt about it. But before we even raise this question to the broader audience I want to make sure all maintainers are in favor if this change.
I do not want to waste my time on trying to convince others if I got no support from co-maintainers, if we are not all on board with this then we can just close this ticket and forget about it. |
To be honest, I deem that Safe Haskell failed to deliver any tangible benefit. The amount of packages, which can be marked as No sizeable real-world application can afford limiting its dependencies to I think there are two approaches, which have better value/breakage ratio:
|
When it comes to constructors unboxed vectors are worst offenders. There're 2 constructors for each type. Curiously mutable module exports them and immutable doesn't (likely by accident). We also could do deprecation for constructors using pattern synonyms: rename constructor and add depreated pattern synonym with old name. Creating separate vector-safe seems like a lot of work with little benefit. We could add |
Looking at the pushback at the maintainer level I am inclined to stop pursuing this split and leave things as they are: safe+unsafe living together in harmony. It seems thought that we all at least agree that:
Considering my suggestion didn't work, I let you guys decide what you wanna do about exporting unsafe constructors. Here is my response to your comments:
Let's not go that route. It has already been tried and people were against it (see pre vector-0.9.1 versions)
Totally agree, it is not worth it. Moreover, I think safe API should be the default and unsafe to be opt-in, not the other way around. But it doesn't look like others share my concerns, so I am not gonna try to promote this ideology any further.
Completely disagree on this one. There are plenty of sizable projects that I am personally acquainted with that only use a small subset of safe function from vector package. Also, what is more important? Couple sizeable projects or thousands small ones? Closing this ticket as a "won't fix". I am sure someone else in the future will revive this conversation once more, maybe then the outcome will be different ;) |
This is a proposal and hasn't been set in stone yet. Please feel free to comment your opinion on the matter in this ticket.
Prelude: It has been requested many times that we provide access to all constructors from
vector
package. Giving access to those constructors allows violation of many invariants and hence is unsafe. Quote from #357:The best approach to tackle this is to create special
Unsafe
modules and export such constructors form there. This also spawned a discussion that it would make sense to migrate all of the of the unsafe functions to such modules (eg.unsafeIndex
,unsafeRead
, etc.), in order to provide a clear boundary between safe and dangerous functionality, which can have different qualified imports in the user land.Doing such migration of unsafe functionality is worthwhile in a long run, but immediate problem is that it will cause a lot of breakage. Therefore it would have to be done in a few stages across couple of major releases.
vector-0.12.2.0
would be adding these modules with all of the unsafe functions exported from there:vector-0.13
, would continue to export all unsafe function from the Unsafe modules and their current locations, but latter ones would getDEPRECATED
pragma added to them. This way such change will be visible to all the usersvector-0.14
would have those unsafe functions removed from their current locations, but only if such release happens at least a year aftervector-0.13
that deprecated unsafe functions.Other relevant points to discuss:
Generic
unsafe functions?The text was updated successfully, but these errors were encountered: