Conversation

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).
1
1
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 😅
2
1
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.
1
1
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
1
1
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
1
1
Found an old talk that might be of interest! Sorry if I sound like I'm shilling this stuff pretty hard – there is a bunch of stuff that would need to be done to make this work for systems programming, but I think it seems promising!
I'm not sure about the specifics of SIMD, but I think there are levels of SIMD support for different processors? You could that support as part of the API, and ensure that certain properties have been checked for before calling certain ops.
1
1
Show replies