Tracking issue for RFC 1861: Extern types

[aturon]

This is a tracking issue for RFC 1861 "Extern types".

Steps:

• Implement the RFC (Implement RFC 1861: Extern types #44295)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• Rust does not support types that don't have dynamically computed alignment -- we need the alignment to compute the field offset in structs. extern type violates this basic assumption, causing pain, suffering, and ICEs all over the compiler. What is the principled fix for this?

• Should we allow generic lifetime and type parameters on extern types?
  If so, how do they effect the type in terms of variance?

• In std's source, it is mentioned that LLVM expects i8* for C's void*.
  We'd need to continue to hack this for the two c_voids in std and libc.
  But perhaps this should be done across-the-board for all extern types?
  Somebody should check what Clang does. Also see "extern type" should use opaque type in LLVM #59095.
  RESOLVED because all pointer types are ptr now.

• How should this interact with unsized arguments? Currently it ICEs: unsized_fn_params should not accept types that don't have a dynamically fixed size (such as extern types) #115709

[jethrogb]

This is not explicitly mentioned in the RFC, but I'm assuming different instances of extern type are actually different types? Meaning this would be illegal:

extern {
    type A;
    type B;
}

fn convert_ref(r: &A) -> &B { r }

[canndrew]

@jethrogb That's certainly the intention, yes.

[glaebhoerl]

Relatedly, is deciding whether we want to call it extern type or extern struct something that can still be done as part of the stabilization process, or is the extern type syntax effectively final as of having accepted the RFC?

EDIT: rust-lang/rfcs#2071 is also relevant here w.r.t. the connotations of type "aliases". In stable Rust a type declaration is "effect-free" and just a transparent alias for some existing type. Both extern type and type Foo = impl Bar would change this by making it implicitly generate a new module-scoped existential type or type constructor (nominal type) for it to refer to.

[Ericson2314]

Can we get a bullet for the panic vs DynSized debate?

[plietar]

I've started working on this, and I have a working simple initial version (no generics, no DynSized).

I've however noticed a slight usability issue. In FFI code, it's frequent for raw pointers to be initialized to null using std::ptr::null/null_mut. However, the function only accepts sized type arguments, since it would not be able to pick a metadata for the fat pointer.

Despite being unsized, extern types are used through thin pointers, so it should be possible to use std::ptr::null.

It is still possible to cast an integer to an extern type pointer, but this is not as nice as just using the function designed for this. Also this can never be done in a generic context.

extern {
    type foo;
}
fn null_foo() -> *const foo {
    0usize as *const foo
}

Really we'd want is a new trait to distinguish types which use thin pointers. It would be implemented automatically for all sized types and extern types. Then the cast above would succeed whenever the type is bounded by this trait. Eg, the function std::ptr::null becomes :

fn null<T: ?Sized + Thin>() -> *const T {
    0usize as *const T
}

However there's a risk of more and more such traits creeping up, such as DynSized, making it confusing for users. There's also some overlap with the various custom RFCs proposals which allow arbitrary metadata. For instance, instead of Thin, Referent<Meta=()> could be used

[SimonSapin]

I think we can add extern types now and live with str::ptr::null not supporting them for a while until we figure out what to do about Thin/DynSized/Referent<Meta=…> etc.

[plietar]

@SimonSapin yeah, it's definitely a minor concern for now.

I do think this problem of not having a trait bound to express "this type may be unsized be must have a thin pointer" might crop up in other places though.