Conversation

Oh no I mean like the type-level function arrow. Like, the type `A => B`

ohhh yeah we decided fn() was fine for the simple case and for the complex case uhh so it turns out we have three different function traits :D

FnOnce<Args> call_once(self, Args) -> Output FnMut<Args> call_mut(&mut self, Args) -> Output Fn<Args> call(&self, Args) -> Output

yeah… really screams out for some sort of polymorphism over closure usage… or something like that

tbh this is fine? because they're all supertraits and because lifetimes, ownership, and mutability matters, you can and indeed must specify the strictness of your trait bound, which lets you accept either all closures (FnOnce) or ones that are safe to call repeatedly (Fn).

Yeah I agree it works fine in Rust, yeah… but I think I'd want closures to be able to support other substructural properties beyond what Rust supports? And then you start getting more and more traits? But yeah I haven't thought it through carefully yet 😅

6:23 AM · Sep 28, 2021Twitter Web App

Thinking about stuff like information flow, stage, and usage counts - say if your language supported being able to specify a range of times a closure can be used.

Mmm, fairly limited gain from going from FnOnce for 0 | 1 calls FnMut for 0..X calls Fn for 0.. calls to Fn [X] for 0..X calls because while the X is hidden in FnMut you can wrap Option and return Some until None.

Replying to

I'd say you'd want something more like: Fn [0..1] for FnOnce Fn [0..] for Fn Fn [0.., Unique] for FnMut (not sure about this one) This would also give you other stuff, like: Fn [1] for a closure that *must* be used

Replying to

But yeah, there are lots of unknowns, but I'd encourage you to look at some of the Granule demos that show some of the automation and error checking you get from the more precise types