Rust Needs an Official Specification • Hacker News Board

Re: Rust Needs an Official Specification

#51

Post by kazinator » Wed, Nov 13, 2024, 2:52 AM UTC

steveklabnik wrote: post #26

gpderetta wrote: post #23

Earlier quoted context omitted.

But in this it is not. let _tmp = Foo; The confusing bit is renaming the object from _tmp to _ changes the rules. I assume that in rust '_' is not an actual name, but a pattern to be matched, but even that the actual rule applied is not obvious (does it match everything? Only the lifetime of objects matched with a name is extended?)

Correct, _ is a pattern that does not bind to any name. While the implications of that may not be simple, the description certainly is. Names that start with underscores are still names, and work like any other name. The “unused variable” into can be suppressed with a leading underscore like any other name, but that’s purely about the lint and not semantics.

I independently came up with a similar hack in TXR Lisp. When a variable is named by a gensym, unused warnings are suppressed. Gensyms are almost always symbols generated by macros. Machine generated code often has cases where variables are unused.

This design decision is a trade off. Any situation in which a variable is unused is potentially a bug, even if the variable is in code written by a macro and named by a generated symbol.

But it is a burden on macro writers to ensure that all possible cases of general code are free of unused variable warnings.

Re: Rust Needs an Official Specification

#52

Post by kazinator » Wed, Nov 13, 2024, 3:02 AM UTC

jmyeet wrote: post #35

gpderetta wrote: post #23

Earlier quoted context omitted.

But in this it is not. let _tmp = Foo; The confusing bit is renaming the object from _tmp to _ changes the rules. I assume that in rust '_' is not an actual name, but a pattern to be matched, but even that the actual rule applied is not obvious (does it match everything? Only the lifetime of objects matched with a name is extended?)

Those are two different things. - A _ prefix tells the compiler not to warn you a variable isn't used. - A _ variable name is a reserved symbol to say something cannot be used. Trying to do so will cause a compiler error. So they're scoped differently. Consider this Go snippet: func A() { fmt.Println("A") } func B() { fmt.Println("B") } func main() { var B = A; B() } What function gets called? It's A but you can reas…

If B is called, and the language is otherwise reasonable, then it must mean that there's an A variable in the program which is not showin in the above code.

The language must have separate namespaces for functions and variables. But in that case var B = A must be resolving A in the variable namespace; it does not refer to the function A. The local B variable is initialized from some nonlocal A variable, and neither of those are related to the A or B functions, nor have any interaction with the B () call which ignores the variable space, looking up in the function space.

Re: Rust Needs an Official Specification

#53

Post by francasso » Wed, Nov 13, 2024, 9:07 AM UTC

I think this is a thorny issue.

On the one hand standardization stiffles development and can even make the language worse going forward.

On the other I really think that before governments start pushing for Rust adoption it should be standardized, i.e. there should be an official document that explains the correct semantic.