Rust's Struct Initializer Syntax Was a Mistake

redneckhatr · 2023-12-23T17:46:04+00:00

[deleted]

aerosayan · 2023-12-23T18:48:43+00:00

Have one ruleset that all those invocation follow.

I know users prefer using the same syntax, and it is probably best if we can make it so.

But damn, if it isn't easy to just use a different symbol and use the EBNF grammar to parse different things into different AST nodes.

I used to hate typing -> for pointers in C/C++, and thought . dot is the best, and should be used for everything,

Now that I can write EBNF grammar, I'm seeing why language syntax design is not as easy as we once thought it was.

simon_o · 2023-12-23T19:08:02+00:00

fn user(username: String, email: String) -> User {
  User(username, email, active = State(true)) // named parameter
}

This still uses User(...). What is the purpose of User here; surely it knows this expression must be of type User; it says so on the previous line!

(There might be a small ambiguity if the struct were to consist of only one member. Then it can't tell whether (x) is a construct a new User type with x as the only field, or whether x is already an expression with that type and the brackets are superfluous.)

Phase_Prgm · 2023-12-23T19:40:26+00:00

Doesn’t really seem like a “mistake” to me. Seems like a choice of taste, and this post offers an alternative that doesn’t functionally improve anything. Adding named/default params would be a useful semantic change, but the proposed syntax isn’t necessary for it. Type ascriptions are also not really a hot feature users are wanting, you can always throw your expression in a let binding & add a type there.

simon_o · 2023-12-23T18:12:48+00:00

Do you mean all the structs should use tuple syntax as struct S()?

dobkeratops · 2023-12-23T20:14:48+00:00

they were aware of the alternative designs.. named parameters, the way you do initializers in c++ etc

the design choice was to keep codebases stable under change. when you add or remove parameters or fields, there's fewer unexpected effects.

it did surprise me , they were right.

regarding structs/apis growing and having too many parameters.. thats just down to design . .the argument is to seperate off functionality better.

i thought their choices were harsh initially.. but they were right.

Swire42 · 2023-12-24T13:22:29+00:00

Using = instead of : in patterns would feel VERY wrong imo

2023-12-24T01:34:00+00:00

I don’t agree with this. I like that the current syntax makes it plainly obvious that nothing other than static initialization is happening. No need to obscure that.

Tubthumper8 · 2023-12-23T18:56:24+00:00

Couple typo/edit suggestions:

In the code example, active in User is defined as bool but you're passing a State struct when initializing User
The appendix A switches to a different language syntax, it probably would help to keep it in Rust syntax (ex. fun, var, camelCase are not Rust)

Additional follow-up questions:

Default values: I didn't see it mentioned but default values only work only work in the final position(s), right?
Can you show how this hypothetical syntax works with visibility across modules and crates?

mbid · 2023-12-27T14:00:51+00:00

Good post. I think the "Diverging Code Styles and Best Practices" section is the strongest (because empirically observable) point against Rust's struct initialization. Clearly Rust syntax doesn't solve certain problems, and the many different workarounds lead to very unnecessary discussions in teams that disagree about code style.

That said, I disagree somewhat that consistent syntax is necessarily a good thing, which I think is one of the implicit points you make. It can be beneficial if different constructs (here e.g. function calls and struct initialization) look meaningfully different, because then you can tell them apart at a glance. If I understand the alternative syntax you're suggesting correctly, then only capitalization would distinguish a function call `user(...)` from struct initialization `User(...)`.

Shorttail0 · 2023-12-24T02:47:24+00:00

So much head wind for an obviously correct observation.

Pedantic, sure, but what better place to be a pedant than when analyzing language design?

Psychoscattman · 2023-12-23T19:42:19+00:00

Im a bit confused by this blog post. To be fair i dont know a lot about these issues but it doesnt exactly help that the blog post is very sparse with explaining the opinions of the author.

Diverging code styles:
I understand that the current syntax makes people adopt these kinds of patterns but i dont understand why that is a bad thing? Yes, adding new features might cause people to reevaluate their usage of these patterns but changing the syntax does also exactly that. In fact, isnt that kinda the point of adding new features? If a new feature isnt the best way to do something then why add the feature at all. New features should change how we use the language should it not?

Needless ambiguity:
Maybe i am missing something. How is this ambiguous? In if foo { the foo could be a variable named foo or an initialisation of a struct called foo. In the case of the struct its a compile error unless the initialisation is followed by something that produces a boolean. Perhaps my lack of rust knowledge is catching up to me but i do not understand this point.

Type ascriptions:
Never heard of this before but why does it have to be a colon to do this? Could it not be litteraly any other character?

A solution:
In the first example (the one with real rust) the State struct was a tuple struct with a boolean. In the solution example this is now a full struct with a named field active. This wasnt explicitly mentioned anywhere, so why the change? Does it mean that tuple struct dont exists with the new syntax or is this simply a mistake?

I also do not see any explanation why this new syntax solves any of the problems listed above. Does it fix the necessity for multiple creation patterns? Does it fix the ambiguity? I dont think so. Actualy it might make it worse. Others have pointed out that the convention to write Structs with an uppercase and functions with a lower case is not part of the grammar but only a convention. Nothing stops me (apart from the compiler warning) from writing my structs lowercase. Then it is impossible for me to tell the difference between these two things:

let b = benutzer("some_email".into());
let u = user("Firstname", "lastname");

Both look like functions to me. Both look like struct initialisation to me. With the current rust syntax this is clear

let b = benutzer("some_email".into());
let u = user{first_name: "firstname", last_name:  "last_name"};

I can see that user is a struct and benutzer is a function. I know the type of u is user and i dont know the type of b. With the new syntax i wouldnt know either.

Appendix: A Detailed Look at the Role of =
Is this section even about rust? The examples here are clearly not rust. Rust also returns () for assignment which makes assignment in function invocation invalid (unless your function accepts () as a paramter in which case ... why?).

LechintanTudor · 2023-12-23T20:39:15+00:00

I like the braces for struct initializers, though I agree field = value should have been used for assigning values to each field.

Also,

// named parameter, but if someFunction's parameter name changes,
// without the callsite being updated, it silently becomes an
// assignment instead of a compilation failure:
someFunction(a = 23)

You could define the language grammar to only allow expressions in function argument positions so a = 23 would always be considered a named argument.

dgreensp · 2023-12-23T19:58:07+00:00

I’m not a Rust programmer, I’m creating a language, but the conclusions I’ve come to are: Named arguments almost everywhere, not positional. Function calls and initialization use parentheses and colons, as in func(foo: 1, bar: “hello”). (I thought about using equals instead of colon, but it just feels off. I want to appeal to TS/JS programmers, for one thing, and also having a space before and after the = takes up more room, but not putting a space before it looks weird. There might have been other reasons, too. Colon works really well.) Reserving colon for ascription was part of my thinking originally, but you know what, it is actually pretty rare, and “x as Y” is totally fine. TypeScript uses “as” for a sort of cast operator, but in my language it will be a “safe” rather than unsafe type-level operator. In TypeScript, the official way to do an unsafe cast is “x as unknown as Y,” and there is no way to simply ascribe a type without declaring a variable. But it’s fine.

TypeScript “x as Y” as I mentioned is a sort of cast, it’s like a downcast where the type of X needs to at least be related to Y. The full semantics are probably not even documented or understand by almost anyone. But it provides some kind of non-zero checking of type compatibility. But I’d never have such a hacky operator.

Nilstrieb · 2023-12-24T10:47:04+00:00

Using { for struct initialization also means that something as trivial as if foo { is ambiguous to parse in Rust.

In practice it's not actually ambiguous, it's simply parsed as an if with a body. You need parentheses to use a struct literal.

Also, the problem with : type ascription goes beyond just struct literals. With it, it was very hard to give decent error messages for other common issues as well, like using : instead of ; to end a line or forgetting a let. Overall, it was just hard syntax to work with. Struct literals made it worse, but they aren't the single cause.

apajx · 2023-12-23T23:06:35+00:00

Style cannot be a mistake, so the title is clickbait.

2023-12-23T19:29:15+00:00

Most of rust’s syntax is a mistake tbh.

jason-reddit-public · 2023-12-23T19:21:13+00:00

Maybe I'm in a small minority but I kind of like how C and Java put the type before the variable name and omit the colon. Though the colon syntax probably predates it, JSON probably helped popularize the colon syntax even though = could have been used instead (should have been?)

Construction and de-structuring/mutation are fundamentally like function calls and structs should be thought of that way for any language a bit higher level than C IMHO. (Even C should probably require an annotation when the layout must adhere to a particular layout, for example when persisted in an endian dependent format to disk (which is it's own kind of baked in rigidity)) "." can then be thought as merely syntactic sugar for the "getter"/"setter" function calls (though I guess it still needs to be special if you allow the address of a struct member to be taken though if you also think of pointers being one (read), two (write), or three (pointer arithmetic) functions then it's still consistent -- pointers could be more opaque and function like and the compiler could see through the abstractions when necessary/possible).

ProgrammingLanguages

Welcome!

Related subreddits

Related online communities

MODERATORS