Re:Rust 2024 the Year of Everywhere?
by woodruffw on Thursday September 22, 2022 @10:46PM
(#32947425)
See my response to 'kibwen. We can nitpick all day about whether it's really a separate language; I think it satisfies at least one important definition of "language" by having its own separate syntax and semantics that aren't accessible to Safe Rust.
[ Parent
| on HN ]
Re:Rust 2024 the Year of Everywhere?
by p1necone on Thursday September 22, 2022 @10:56PM
(#32947494)
But by that argument every feature in a language is it's own separate language. "This is the language that can only be written inside function definitions", "This is the language that can only be written inside ternary operators" and so on.
Re:Rust 2024 the Year of Everywhere?
by woodruffw on Thursday September 22, 2022 @11:08PM
(#32947554)
Sure: you can clearly drive this to absurdity.
The list I gave was the ones I've heard people in the Rust community, including official Rust language documents, refer to as separate languages. Does that guarantee that we're carving the nature of "computer language" at its joints? No; it's merely a shorthand for expressing the range of syntaxes and semantics that you need to know to "fully" know Rust.
What syntax is different with unsafe?
Re:Rust 2024 the Year of Everywhere?
by woodruffw on Thursday September 22, 2022 @11:21PM
(#32947634)
Unsafe Rust's syntax is a superset of Safe Rust, meaning that there is syntax in Unsafe Rust that will not compile in Safe Rust[1].
[1]: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
It's the same syntax. There are no special operators in unsafe rust. All unsafe code is syntactically valid safe code. The reason it will not compile it because certain operations are not permitted, not because of syntax errors
That doc needs to be rewritten. By that logic, closure Rust is another subset, and Iterator, so are pub (crate) modifiers, etc.
It just allows access to: raw pointers, unsafe fields and methods, and unsafe traits.