In #319 @nikomatsakis motivated the introduction of support for tracked methods (i.e. associated functions with a self argument).

I would like to propose extending this to type-level associated functions (i.e. without self argument) as well.

Tracked associated functions would have to follow the same function signature rules as their equivalent free functions.

As such the following:

#[salsa::input]
struct MyInput { ... }

#[salsa::tracked]
struct MyOutput { ... }

#[salsa::tracked]
fn output_from_input(db: &dyn crate::Db, input: MyInput) -> MyOutput { ... }

// ...

let input = MyInput::new(db, …);
let output: MyOutput = output_from_input(db, input);

… could be rewritten as such:

#[salsa::input]
struct MyInput { ... }

#[salsa::tracked]
struct MyOutput { ... }

#[salsa::tracked]
impl MyOutput {
    #[salsa::tracked]
    fn from_input(db: &dyn crate::Db, input: MyInput) -> Self { ... }
}

// ...

let input = MyInput::new(db, …);
let output = MyOutput::from_input(db, input);

While I'm using a "constructor" function here as a motivational example, they are obviously merely one of may use cases for tracked associated functions.

As such support for tracked associated functions would allow for neatly grouping tracked functions into (even untracked, and otherwise unrelated) types:

#[salsa::input]
struct MyInput { ... }

#[salsa::tracked]
struct MyOutput { ... }

struct OutputGenerator;

#[salsa::tracked]
impl OutputGenerator {
    #[salsa::tracked]
    fn output_from_input(db: &dyn crate::Db, input: MyInput) -> MyOutput { ... }
}

// ...

let input = MyInput::new(db, …);
let output: MyOutput = OutputGenerator::output(db, input);

The OutputGenerator type kind of like acts like a "namespace" type here, but with additional benefits (for those who need id), such as providing the tracked functions access to its associated types (a major limitation of free functions in a "namespace" module).

I'd argue that tracked associated functions would not only fill a gap in salsa's current expressivity, they also tend to feel more idiomatic and and support for semantic grouping (beyond merely showing functions in a common module) makes the code look more cleaned up overall.