val fun: Arg => Ret
def fun(Arg): Ret
when you don't have a function arrow (i.e. =>) then definitely I'd go with ->. but Scala has function arrow
Conversation
we do use => amusingly, but only for match arms.
1
1
indeed we don't, for whatever reason we decided we like Ruby closures better.
1
1
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
1
1
FnOnce<Args>
call_once(self, Args) -> Output
FnMut<Args>
call_mut(&mut self, Args) -> Output
Fn<Args>
call(&self, Args) -> Output
2
1
yeah… really screams out for some sort of polymorphism over closure usage… or something like that
2
1
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
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.
There's hints of this stuff in what Granule is doing, and I'm hoping more progress is going to be made on this in the future. It seems like stuff like this could be rather useful for systems programming, imo.
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
Show replies