fn apply<A, B, C, G>(mut f: impl FnMut(B) -> G, a: A) -> impl FnMut(&B) -> C
// must still be `for<'r> impl FnMut(&'r B) -> C`, because that’s what filter requires
where
G: FnMut(A) -> C,
B: Copy, // for dereferencing
A: Clone,
{
move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements
}
all this did so I could write in my code ...
.filter(apply(second, i))
...Is that not the case? It certainly looks nice, but is it ready for use?
The situation (as I understand it) is unlike using a GC, autofree requires the user to have knowledge of memory management and how to use it properly. One of the objectives of Vlang is to be easy (easier) to use. Using a GC as the default, proved to perform very well with the language, and presented less complications for users.
It appears the strategy of the Vlang developers (as stated on their website and documentation) is to go with flexible memory management. That is the GC can be turned off whenever the user wants (-gc none), and other memory management options can be used such as autofree (-autofree) or their arena allocator (-prealloc).
This flexible memory management strategy would be somewhat similar to what Nim did, and interestingly, I don't see people crying as much about it. Furthermore, there is more to Vlang as a programming language than just autofree, as if its the only thing that counts. People use it for many other reasons.
1. https://www.youtube.com/watch?v=gmB8ea8uLsM (Autofree demo) 2. https://www.youtube.com/watch?v=mJG4Zg6Ekfw (Vinix OS)
This is another one that tries to attack the same surface area as rust but aims at being easier.
There is also Carp by the way: https://github.com/carp-lang/Carp
Lots of people like Vlang, so better to accept that. Not everybody is going to prefer or think the same in regards to programming languages.