back
4 comments
We are still waiting for proper arrays and string, or some form of fat pointers for the last 50 years.

I doubt an ownership system will ever arrive.

AT&T work on Cyclone ended up being picked by Rust instead of anyone at WG14 getting some inspiration for papers.

It is true, I feel pretty lonely in WG14 pushing these ideas sometimes. But it is not that we haven't made progress: When I joined there was only a vague understanding of of the memory model and provenance and even ideas how to make it less reliable in favor of optimization ("wobbly values") etc. We now a a good model for provenance, killed a lot of questionable ideas, strengthened semantics when there is UB (prior I/O is not affected), introduced checked arithmetic, started to eliminate UB from the language (this is ongoing but progressing well), made dependent array types a requirement with concrete plans to add a dependent structure type. On the compiler side tools are also evolving.
I skimmed through those ideas for C2y, hope they make through.
I see a lot of very familiar things there, but with lock ordering declared at compile time. Of course there’s plenty I would need to know more about before I could add to it, but if you were to practice Rust instead of merely commenting about it you would find that the readability improves with usage, same as any other language.
IMO "readability" will always be an issue. It's a natural consequence of making more invariants and pre/post conditions explicit in your code.
I think also pre/post conditions should look readable. But the Rust code referenced in the aritcle looks like what you would give a proof assistant, but then also only if you never plan to look at this again.
I think people tend to underestimate the amount of pre/post conditions needed to ensure that software is correct, and when those are explicitly mentioned they become much less readable than you would expect.
I disagree; it looks pretty straight forward to me. I mean, the first thing in the file is an iterator over all addresses on a device that were handed out via SLAAC (as opposed to being manually configured). It makes complete sense to me that this would need the IpDeviceAddresses<Ipv6> lock. You can’t iterate over a list that is being changed by someone else, so you have to hold the lock that prevents it while you do. That’s very obvious and not at all what a proof assistant would generate.
With my ~2 weeks of Rust usage, that looks pretty readable. You can freely skip over reading some if not most of the boilerplate, reading just the bits actually doing the main stuff (and whatever context you desire), without fear of having skipped out on some safety-critical part.