Variables and fields in generics

[Soni]

The ability to set generics not just on lifetimes and types and consts but also on variables and fields would provide statically checked guarantees and flexibility that we can’t have yet.

For example, imagine a variable generic and a JoinGuard built from variable generics. Imagine a struct such that (uhh see my post about function names in generics - but imagine that the function can optionally accept “userdata” defined and constrained by variable/field generics)

[shingtaklam1324]

So I'm assuming what you mean is like what Go has for interface? There has been RFCs discussing using a struct's field in Traits, but that was a while ago and I'm not aware of any recent activity.

What do you mean by variables? Like class variables in Ruby? Rust doesn't have those.

Fields in Traits

It also effectively prevents enums from implementing the trait. I’d like to see some way to weasel oneself out from the necessity of a there to be an actual backing field – even if it were unsafe: one could override the “fieldness” with an unsafe implicitly called method that returned a reference to a memory location, and the unsafe code promises not to have side-effects and that the memory location is disjunct from other memory locations provided by the other fields. Of course this is just a st…

is the previous dicussion on this, highlighting the currently many downsides to it.

[Soni]

for variables:

let x = FooBar::new();
let y: JoinGuard<x> = thread.join_guard(); // or something idk
// trying to leave the scope either requires the guard to drop or errors
// I'm not sure if this is sound. but it's not the use-case I originally had in mind (see below)

for fields:

fn bar<let v>(x: Idk) {
    v.push(x)
}
struct Foo {
    x: Vec<Idk>,
    y: Controller<bar::<Self::x>>
}

// elsewhere
foo.y.push(idk) // --> foo.x.push(idk), through bar

(they’re basically the same basic concept, just applied differently. do you think we can do monomorphization with what’s basically closures?)

[Centril]

So this is about dependent types.

See: Variable dependent types?

[bbatha]

For variables, I’m not sure why your example couldn’t be:

let x = FooBar::new();
let y: JoinGuard<FooBar> = thread.join_guard_with_resource(x); // could be a builder, or varidics if rust ever gets them

For fields it sounds like you’re describing delegation and possibly inherent impl extension methods, i.e. allowing other crates to implement stuff like impl Struct {...}

[Soni]

This isn’t about dependent types - those are about constraint checking. This is about passing variables and fields (a la &mut) at compile-time, using monomorphization.