This is mainly a question for @noamtashma, but possibly of interest to @steffahn. This forum is the only way I know how to reach out. That said I don't want to discourage anyone else from commenting.
I have raised a PR in the safer-owning-ref repo that should fix the last soundness issue in the "primary" API, by using the maybe-dangling crate
However, some of the other peripheral features in the crate (to be fair they are marked unsafe) are unsound in ways I can't get miri to be happy with. Namely the map_owner and type erasure features.
So I am asking if you would be happy if I published a "minimal-owning-ref" crate with about half the features (and all the deprecated methods) removed. This is the branch I have in mind (minus some final readme updates and other cleanups)
I want to make sure I'm not stealing your prerogative, since your vision for this crate is probably better-considered than mine.
Thank for your work on this and other crates.
I had seen (i.e. gotten a notification, not looked into it) the PR already (you misspelled safer_owning_ref btw 
). I don’t think there’s necessarily too much sense in publishing yet another fork, especially in case the motivation is just soundness; on the other hand it’s all open-source, so you do you.
The main reason why API like map_owner even still exists there, as far as I understand & remember, is to offer easier more better compatibility to & transition from the original owning-ref crate. The only reason why safer_owning_ref even exists is because the original owning-ref crate is unmaintained. The original version is also still remarkably heavily used,
so IMHO it would be most useful to the ecosystem to consolidate on a single fork and make it as sound as possible. I think it would be desirable to achieve a maximally compatible (for easy switching) yet as-sound-as-possible API.
Sure, a more minimized – or perhaps even redesigned from scratch – API might be an interesting project, too.
But as far as the soundness, e.g. of map_owner in particular, is concerned, when its already an unsafe method, it would probably just need some relevant extra documentation as to what kind of “owner” types can’t support it at all under current miri semantics.
For more details or the possibility&impossibility of handling of other problematic APIs, I’d need to look at the PR properly first 
1 Like
Hi. No, don't feel like you're stealing my prerogative. This isn't really my crate in the first place. I originally wanted the original owners to update their version (which still gets the vast majority of downloads) but I never managed to contact them.
Also as you could've noticed I haven't changed the crate at all for quite some time, But I will gladly look over your PR.
My version is mostly supposed to be a plug-in replacement to the original, so I'm probably not going to remove unsafe methods unless it's impossible to use them soundly.
Of course if you can expand on why you think I should remove them I'll gladly consider it (I just think it's unlikely I'll decide to remove them).
Thanks for taking the time and writing a PR If I don't get around to looking it over feel free to remind me.
1 Like