3 ms·
I don't see the difference between having a typed access API (V inline reg_at(enum K k) {} ) and overloading the indexer. If your point is that historical C AP
by mjburgess 2y ago
I don't see the difference between having a typed access API (V inline reg_at(enum K k) {} ) and overloading the indexer.
If your point is that historical C APIs have overused an untyped operation, that's part of my point about a new std lib. Rust APIs can still provide an untyped indexer, it's just bad API design.
What I'm imagining a new std lib would be doing is having debug allocators, metadata against types, etc. Ie., a std library designed for the debugger along with a release version.
- jcranmer 2y agoUsing different enums doesn't help, because C will happily let you cast enum A to enum B implicity. In Rust, I can express an API which can't be used incorrectly. In C, I can't. Sometimes, in C, you can sometimes get to the point where you use conventions that means maybe static or dynamic analysis tools might be able to flag the misuse of the API, but very often, such tools have extremely poor tradeoffs between precision and accuracy, far worse than exists in Rust with just the vanilla compiler.
- mjburgess 2y ago-Wconversion , no? My point isn't that you exhaust all the features of Rust with a better stdlib and "debugger-oriented programming" -- my point is that you can get 95% of the way there with trivial complexity costs. Rust imposes significant program design costs which can be very detrimental to otherwise trivial performant memory management, to faster iteration of software design, and so on. These aren't free lang. features.