Facet implementation for type with invariants

[tyilo]

Is it supposed to be safe to implement Facet with #[derive(Facet)] for a type that has internal invariants?

If so, then facet_json::from_str needs to be unsafe:

use facet::Facet;

type T = u64;

#[derive(Facet)]
pub struct MyVec {
    pub inner: Vec<T>,
}

#[derive(Facet)]
pub struct AtLeastTwoVec {
    inner: Vec<T>,
}

impl AtLeastTwoVec {
    pub fn new(v: Vec<T>) -> Option<Self> {
        if v.len() < 2 {
            None
        } else {
            Some(Self { inner: v })
        }
    }

    pub fn second(&self) -> &T {
        // SAFETY: `inner` has at least length 2
        unsafe { self.inner.get_unchecked(1) }
    }
}

fn main() {
    assert!(MyVec::type_eq::<AtLeastTwoVec>());

    let v = MyVec { inner: vec![1] };
    let peek = facet_peek::Peek::new(&v);
    let json = facet_json::to_json_string(peek, false);

    let v: AtLeastTwoVec = facet_json::from_str(&json).unwrap();
    dbg!(v.second()); // Undefined behavior
}

[fasterthanlime]

Is it supposed to be safe to implement Facet

No, Facet is an unsafe trait.

[fasterthanlime]

But.. yeah. I see what you mean.

I don't think unsafe derives are a thing yet, really?

[Veykril]

But.. yeah. I see what you mean.

I don't think unsafe derives are a thing yet, really?

Not yet rust-lang/rfcs#3715

[tyilo]

I think this should be mentioned in the documentation for both the Facet trait and the Facet derive macro.

Maybe the derive trait can be renamed to UnsafeFacet to make this apparent?

[tyilo]

What is the plan for implementing Facet for NonZero<...>?

[fasterthanlime]

If so, then facet_json::from_str needs to be unsafe:

Maybe that's just the solution. It's true that building any type of the deployments facet is inherently unsafe unless you know what you're doing? I don't know.

Maybe the solution here is to expose some method to verify invariants? It wouldn't solve the naming issue or the documentation issue, but we could make from_str return an error if it actually deserializes into something that is not supposed to be representable.

I quite like this idea. In fact, it could be specified as an attribute in the derived macro, something like:

#[derive(Facet)]
#[facet(invariant = Self::at_least_two)]
pub struct AtLeastTwoVec {
    inner: Vec<T>,
}

Or something. It could even return an error value instead of just a bool so we have a nice user experience.

[JSorngard]

serde allows one to deserialize into an intermediate type and then implement a check for the invariant in a TryFrom implementation: https://serde.rs/container-attrs.html#try_from. Might that structure be interesting here?

Example:

#[derive(Deserialize)] 
#[serde(try_from = MaybeFive)] 
struct NotFive {
    int: i32, 
} 

#[derive(Deserialize)] 
struct MaybeFive(i32); 

impl TryFrom<MaybeFive> for NotFive {
    type Err = FiveErr;
    fn try_from(val: MaybeFive) -> Result<Self, Self::Err> {
    if val.0 != 5 {
        Ok(Self { int: val.0 })
    } else {
        Err(FiveErr)
    } 
} 

struct FiveErr;

impl Display for FiveErr {...}

[tyilo]

Should Facet be able to be implemented for structs with invariants that can't be checked at runtime?

Such as:

struct MyByteVec {
  // Safety invariant: `ptr` points to `len` bytes of memory
  ptr: *mut u8,
  len: usize,
}

I think MyByteVec should be able to implement Facet, however it can't implement any safe deserialization.

[fasterthanlime]

Should Facet be able to be implemented for structs with invariants that can't be checked at runtime?

Yes, but not through the derive, if that makes sense?

I really don't like the UX implications of renaming the derive macro to anything other than Facet, but... Someone from the compiler team was just asking me what we would need to make more progress on facets, so maybe we can get those unsafe derives shipped sooner rather than later??

[fasterthanlime]

I really don't like the UX implications of renaming the derive macro to anything other than Facet, but...

I'm starting to change my mind.

[madsmtm]

I'm not sure I agree with the first example being the fault of the Facet derive; rather, it's the unsafe { self.inner.get_unchecked(1) } that's wrong, because you implemented Facet, and thus the type no longer upholds its invariants.
It'd be the same situation if you'd implemented Default, and we don't mark that trait as unsafe (remember: any unsafe extends to the entire module, just like Unpin is safe but can cause unsoundness elsewhere if implemented wrongly).

Are there other examples of Facet being unsound? If not, then I don't think it needs to be unsafe.

[fasterthanlime]

It'd be the same situation if you'd implemented Default, and we don't mark that trait as unsafe (remember: any unsafe extends to the entire module, just like Unpin is safe but can cause unsoundness elsewhere if implemented wrongly).

That's actually a really good argument!

[JSorngard]

It's also the logic serde uses. Deriving serde::Deserialize has these same pitfalls as deriving Facet does.

Though a method for enforcing invariants during deserialization would be very nice.

[fasterthanlime]

Though a method for enforcing invariants during deserialization would be very nice.

Any ideas on how to allow returning errors there without falling into "no context" or "&'static str only" or "woops we require an allocator now"?

It would be nice to get the details of what invariant failed.... maybe &'static str is not that bad.