Comment by Ar-Curunir
3 years ago
FWIW you can easily write Rust in a C-like style, using primarily free-standing functions and structs. You can opt-in to “advanced” features (traits, enums, generics) as you see fit.
Interfacing with other libraries, is ofc, a different matter, but you can usually wrap the library API in your own functions to minimize this mismatch.
All of Rust's functions are available as "free-standing functions" because of how types work in Rust, and Rust doesn't have classes, just structs. So, as a consumer nothing changes.
... is perfectly legal Rust, it would just be more idiomatic to write:
The availability of all functions as "free functions" is convenient when you need, say, a filter predicate, since of course std::collections::HashSet::is_empty is exactly what you wanted if what you wanted to express was the predicate "is this HashSet empty?" and in languages that aren't allowed to do this you'd need to pointlessly shuffle chairs around to achieve the same thing instead.
Yup, that's a good point, UFCS means that every method/function is free-standing =)
Universal Function Call Syntax goes both ways, Rust only offers to treat all of the things that seem like "methods" as free functions but not the reverse.
Under UFCS I could extend your Rust type by simply writing a new free function which matches the type, and this is in fact deliberately forbidden. (I can write the free function, but, doing so does not extend the type and I can't call it using the "method" syntax).
You can, but it's not like the Rust std-lib is in that style, nor does it play well with the ownership semantics, so my point stands.
You can also write literal C and use the C std-lib in C++ but it is the same problem. You're not using C++ at that point
You can use every rust API in that style, even if it wasn't written like that. See the sibling comment here: https://news.ycombinator.com/item?id=30472226
If you think what we're talking about amounts to having a . or not then you have no idea what we're talking about.
Rust's stdlib assumes not only that there is malloc behind the scenes, but that it is ok to panic. Rust itself, including its stdlib, lacks a stable ABI. It also assumes that lots of little allocations and deallocations with a single owner is a valid memory pattern, and that writing directly to specific memory locations is something you never want to do. These are all wrong assumptions for someone writing baremetal. Look up abi_stable and no_std.
2 replies →