The first gotcha I checked for is whether Box<T> and &mut T are correctly handled. Glad that’s covered! Though, my understanding is that BowlRef currently has no niche, due to internally using MaybeUninit to get the desired properties. That seems unfortunate, though I suppose that can be improved once std::mem::MaybeDangling is stabilized. My personal solution is to create Box and &mut equivalents which use NonNull, which admittedly loses the possible alignment niches (which the compiler doesn’t currently exploit anyway).

I’m worried about what could happen when T::Target contains non-'static data. Such cases can introduce implied bounds that might mess up your unsafe code’s reasoning about for<> binders. Combined with contravariance, that can cause problems in yoke (which necessitated some additional bounds to prevent this problem). So, I’m concerned about the map method, for instance.

I’m also not convinced by the safety comment of impl AsRef<BowlRef<'b, T, F>> for BowlRef<'a, T, F>. I don’t see why invariance can’t cause unsoundness. I’ll try to explore some edge cases.

I actually found the aliasable crate using the same NonNull solution, too. I like this approach pretty much but it makes the API more complicated.

I would like to hear more about the implied bounds as I figured it's currently an undocumented behavior of HRTB. About AsRef, I'm not claiming that the View<'_> is covariant or contravariant. My proof is to argue that View<'_> can be valid for all lifetimes despite being invariant. And the lifetime used in the struct is merely a placeholder of "all lifetimes" so the major issue is not on AsRef and more on the get()/get_mut() method, I guess.

Thanks! I'll take a look at it.

EDIT: This is a really clever hack. If I'm understanding it correctly, yoke is using whatever lifetime of the reference returned by the constructor. oyakodon might not suffer from this issue because it can distinguish the lifetime returned by the constructor from the lifetime of the owner. So:

use yoke::Yoke;

type F<'a> = fn(&'a ());

fn main() {
    let n = String::from("Hello World!"); // let's call this '1
    let x: Yoke<&'static str, Box<F<'_>>> = Yoke::attach_to_cart(Box::new((|_| {}) as _), |_| &n[..]);
    // infering '_ = '1
    // In oyakodon, `for<'a> F<'a>=&'1 String`
    let y: Yoke<&'static str, Box<F<'static>>> = x;
    let s: &'static Yoke<&'static str, Box<F<'static>>> = Box::leak(Box::new(y));
    let r: &'static str = s.get();
    // here s.get() returns '1 too

    println!("pre-drop: {r}");
    drop(n);
    println!("post-drop: {r}");
}

One of the Views can create an Output for any given lifetime, but that does not imply that any given Output could have been produced from any lifetime.

Counterexample (which triggers UB):

use std::cell::Cell;

use oyakodon::{BowlRef, Derive, View};


struct CellMaker;

impl<'a> View<&'a str> for CellMaker {
    type Output = Cell<&'a str>;
}

impl<'a> Derive<&'a str> for CellMaker {
    fn call(self, input: &'a str) -> Self::Output {
        Cell::new(input)
    }
}

fn main() {
    let bowl = BowlRef::new("Hello", CellMaker);

    {
        let cell = bowl.get();
        cell.set(&"Goodbye".to_owned());
    }

    println!("{}, world!", bowl.get().get());
}

Wow, that was fast! It is a UB. Though I still need some time to figure out why it worked...

I'm currently working on a variance-family crate that makes requirements of covariance (or contravariance, if ever needed) easier to express.

...I lowkey spent all of Wednesday working on a particular issue in the ergonomics of that crate only to give up and declare that Rust's trait solver just cannot perfectly express what I want. So when I say it makes the requirement "easier" to express.... I think that I can move almost all the complexity into variance-family so that its users (usually) get to see sunshine and rainbows, though any edge cases that stray off the happy path require implementing three unsafe traits.

Update on concerns about variance: BowlBox, BowlRef, and BowlMut are each invariant over all their parameters, so concerns about soundness are limited to the explicit cast* methods. No cast methods are capable of changing the owner type, so contravariance of the owner does not matter.

Here's my (failed) attempt to use contravariance + implied bounds to cause unsoundness:

struct StrView<'a>(&'a String);

impl<'a: 'b, 'b> View<&fn(&'b String)> for StrView<'a> {
    type Output = &'b str;
}

impl<'a: 'b, 'b> Derive<&fn(&'b String)> for StrView<'a> {
    fn call(self, _input: &fn(&'b String)) -> Self::Output {
        self.0
    }
}

fn step1<'a>(
    string: &'a String,
) -> BowlRef<'a, Box<fn(&'a String)>, StrView<'a>> {
    BowlRef::new(
        Box::<fn(&'a String)>::new(|_| {}),
        // Oops! `StrView` doesn't implement `Derive<&'c _>` for *all* lifetimes,
        // but thanks to implied bounds, this still works.
        StrView(string),
    )
}

fn step2<'a>(
    bowl: BowlRef<'a, Box<fn(&'a String)>, StrView<'a>>,
) -> BowlRef<'a, Box<fn(&'a String)>, StrView<'static>> {
    // `StrView<'a>` and `StrView<'static>` have the same output for all lifetimes
    // which are at most `'a`, which is good enough thanks to implied bounds.
    bowl.cast_view()
}

fn step3<'a>(
    bowl: BowlRef<'a, Box<fn(&'a String)>, StrView<'static>>
) -> BowlRef<'static, Box<fn(&'static String)>, StrView<'static>> {
    // Since `Box<fn(&'a String)>` can be freely coerced into `Box<fn(&'static String)>`,
    // it sure would be nice if I could map the owner type like that.
    // However, your type is invariant over the owner type and exposes no way to change the
    // owner type.
    // This step is impossible, and is the reason that contravariance + implied bounds
    // do not manage to break your type.
    unimplemented!()
}

I slept over with it and figured that you are totally right about this. get()/get_mut() breaks the HRTB invariant and the view should not be accessed via these methods. I created a safer version, but it's much less ergonomic...

EDIT: I renamed the API.

I found your post about this

It resembles the yoke issue you mentioned?

Exactly, I tried to translate that yoke problem into your crate’s types.

Life would be much easier if only I had some of your primitives like Varying when writing my crate. If I read it correctly, the problem of variance-family (other than soundness) is that the trait solver cannot prove complex tautologies about lifetimes and so users don't get happy times for free? I hit these issues when writing impl PartialEq and had to trial-and-error finding a way to hint the compiler.

Check the dev branch; I think I finally have what I need, though some of the bounds involved are gnarly:

(And yes, I also got those bounds by trial-and-error.)

Now I'm just fleshing out macros and std implementations for variance-family. Then I'll move on to aliasable-view.

Wish you luck with that. This is often the phase where rustc tells me that my brilliant idea does not work.

I fixed all the tests and am ready for another round of soundness challenge!