5 ms·
This is a rather technical post about the precise details of some "internal" Rust semantics... Not exactly designed for a general audience. I'd be interested t
by dbaupp 13y ago
This is a rather technical post about the precise details of some "internal" Rust semantics... Not exactly designed for a general audience.
I'd be interested to hear if people unfamiliar with Rust can make head or tail of it. :)
- mjn 13y agoI'm not greatly familiar with Rust (and have never written it), and I think I was able to follow. If I'm reading correctly, there are certain traits that objects get automatically if the compiler finds they qualify, which in my mind would be something like Java automatically adding the Serializable interface to classes that it concluded were in fact Serializable, and then removing it when you did something that made it no longer automatically Serializable. The proposal seems to be to make it more like Java: you have to explicitly write "implements Serializable", and it doesn't by default. Then presumably some logic would still apply to ensure that it really can be given the trait you ask for. In particular the move/copy/clone semantics would (under this proposal) no longer be chosen automatically. It seems (again, to someone who hasn't used Rust) like a tradeoff between compilers that make smart choices automatically by default when possible (e.g. about representational strategy), vs. compilers that avoid doing surprising things.
- dbaupp 13y agoThanks for the feedback, it seems like you did follow it correctly > In particular the move/copy/clone semantics would (under this proposal) no longer be chosen automatically (Technically, it's just the move semantics: i.e. if passing a value around by-value (i.e. `a = b` like C, shallow-copying the bytes of the values) makes the compiler consider the source unreadable (a move, non-Pod types) or just duplicates the data, leaving the source still readable (an "implicit copy", Pod types).)
- andrewflnr 13y agoI can't tell what your point is. If it's that this is not appropriate for HN, I disagree strongly. If posts relating to a specific technology were not allowed, HN could hardly live up to its name. For myself, this was one of the few immediately interesting things on the front page, despite having little more than passing knowledge of Rust.
- dbaupp 13y agoI was just interested to know if it was interesting to people unfamiliar with Rust; no particular point about it being inappropriate to HN or anything like that.
- bjz_ 13y agoHaving contributed a small amount to Rust, I wouldn't have naturally posted this one to HN because I though it would be of little interest to folks outside the community, but I'm glad it has interested some people! If you are interested in reading more posts like this, they pop up sometimes on our subreddit: http://www.reddit.com/r/rust/ http://www.reddit.com/r/rust/
- dbaupp 13y agoContributed a "small" amount? Bah! You're the one who's been consistently curating std::num for many many months!
- andrewflnr 13y agoMy point is, no one bats an eye when someone posts something that's only relevant to, say, the Python or Haskell community. Further, I bet there are a lot of people like me who aren't really rustites, but are interested enough to want to keep tabs on Rust's progress. Anyway, I mean no offense, only to encourage people to be bolder in posting. :) I'll go subscribe to /r/rust now.
- snogglethorpe 13y agoI know little about Rust (other than some general idea of its goals and approaches, e.g. the explicit attention paid to ownership), but the this article seemed pretty clear to me. It was well-written and made good use of examples, and the underlying issues are found in many programming languages, even if the details here are Rust-specific.
- dbaupp 13y agoAwesome, thanks for answering my curiosity.