Pre-RFC: `=` for struct construction

[mbrubeck]

This was previously proposed as RFC #65.

It was also recently discussed in the users forum.

[MajorBreakfast]

You specifically asserted in the other thread that “just because a language uses the syntax doesn’t mean that it makes sense”. Therefore I find it puzzling that you think “C does this” is a meaningful argument in favor of a wildly breaking change.

I did. And I think that it’s more important to have consistency than to do something another programming language does. Nevertheless it is relevant for the discussion to mention that C99 has a similar syntax.

Also, this proposal won’t break anything. Instead it proposes continued support of the current syntax.

It’s not exactly assigment though, or not necessarily. You can think of it as assignment, but the notion of a “key-value pair” or “name-value pair” is equally valid

Can you elaborate what you mean with “It’s not exactly assigment”? It think it assigns values to struct fields.

[H2CO3]

In procedural speak, you might say “assign”. It’s not changing anything though, so I would actually prefer the term “initializes the field” or “binds the value to the field”. Struct construction is not really about mutating a value, but about constructing a new one from parts.

(I’m not sure what the official terminology for this is, though.)

[Centril]

fn print_area<T: HasArea>

Nit: the : syntax is not used to “define the type” here (I know you didn’t mean this, but it could be textually a bit clearer)

I find the main advantage of this proposal to be the freeing up of the type ascription syntax from the troubles it has been in. I think the proposed syntax is certainly more internally consistent than the status quo. Using the judgemental form x : τ for initializing/updating/binding is deeply strange to me.

That said; Nearly every crate will be touched by this, so this step should only be taken with much care and deliberation.

PS: I think your plan of action (“shipment strategy”) is reasonable proviso that we want to take this step.

[MajorBreakfast]

Nit: the : syntax is not used to “define the type” here

Someone will need to go over this and correct all the terminology blunders. I’m also pretty sure that the assignment expressions I give as an example are actually just the definitions of a bindings. The compiler guys will probably be aghast and say “these differences should be clear to everyone!” ^^’ I just know how to use it

[H2CO3]

This change makes struct construction fully compatible with type ascription in expressions

That should already work with the current syntax though, shouldn’t it? Isn’t let s = MyStruct { a: 42: u64 }; already unambiguous to parse? Field name, colon, then an expression, where the expression can contain an optional type ascription.

And while we are at consistency — another problem with this proposal is this: will it change struct patterns too? If so, will it change them to MyStruct { name = value } as well? Because that doesn’t make sense at all:

match foo {
    Foo { name = 1337 } => …,
}

This looks like the field is being assigned the value 1337 in the pattern, whereas it’s not, it’s a comparison. That’s downright confusing.

[MajorBreakfast]

Type ascriptions should work with the current syntax too, but it doesn’t look very tidy. I continue to think that type ascriptions aren’t useful because the struct has already the types defined. I just wanted to mention how it would look like.

will it change struct patterns too?

I’ve just looked at the old RFC and saw that too. Yes IMO it should. It has to be added to the proposal.

[H2CO3]

Well, that’s even worse (for the reasons I enlisted). That’s not even a subjective consideration, making patterns look like assignments is objectively bad, it’s totally backwards.

[MajorBreakfast]

Destructuring is IMO precisely assignment backwards. ^^’

[H2CO3]

It’s not though, if you look at the example I posted. Nothing is being assigned here, the struct is not even being constructed. Instead, the name field is being compared against a value. It’s misleading to denote it as an assignment of the value to the field.

[Centril]

let my_struct = MyStruct { a = 42: u64 };

If you want to use this particular example, the reader is right to ask: “what about 42u64?”. A different example might show your point better.

Type ascriptions should work with the current syntax too, but it doesn’t look very tidy.

Unfortunately, no. Given the form:

fn main() {
    struct MyStruct { a: u64 }
    let MyStruct { a: foobar } = MyStruct { a: 1 };
}

I would suspect that this is making the typing judgement a : foobar.

That’s not even a subjective consideration, making patterns look like assignments is objectively bad.

I don’t know about “objectively”; but my view is at least that it would be quite confusing / misleading. That said, the current rebind-as syntax is also terribly confusing (with typing judgements).

A possible non-confusing syntax would be:

fn main() {
    struct MyStruct { a: u64 }
    let MyStruct { a as foobar } = MyStruct { a: 1 };
}

[H2CO3]

To be honest, I don’t see how the as keyword, which is currently only associated with type casting, is better in this sense. It would now gain an overloaded meaning of destructuring, compared to : which is already used for two different purposes in two different contexts. (It wouldn’t be different vice versa either, but that’s history.)

[Ixrec]

Regardless of whether = or : is the better syntax, this change implies such a tremendously huge amount of churn that I consider it a complete non-starter.

For comparison, when I wrote the dyn trait RFC, I always felt that was just about the maximum amount of churn we could possibly get away with, and hopefully the churniest change we’re ever going to do after 1.0. And that was a case where the existing syntax was so deeply confusing that people often had no idea they were operating on trait objects rather than traits. Even if you don’t like today’s struct syntax, I don’t think anyone’s found :s so confusing that they failed to understand they were initializing a struct.

[Centril]

To be honest, I don’t see how the as keyword, which is currently only associated with type casting, is better in this sense.

Darn it! Why is everything so jumbled and why can’t we have nice things…

I wanted it to evoke association with:

use path::to:thing as foobar;

… but I see the possible confusing reading you pointed out.

Well; if we want to go “fully unambiguous” (not saying we should) a syntax could be:

let MyStruct { use a as foobar } = MyStruct { a: 1 };

Another syntax comes to mind…:

let MyStruct { a @ foobar } = MyStruct { a: 1 };

[H2CO3]

Oh, and indeed, as already has another meaning, in imports. In this case that argument of mine doesn’t stand as strong.

(I don’t think we should try making this particular case “fully unambiguous” either, btw – the status quo is pretty clear, but granted, it’s certainly possible to come up with something completely non-overloaded. If this had to be changed, though, I would lean towards @ since it is already familiar as a top-level pattern binder, so it would have a similar function, and it wouldn’t introduce lengthy keywords in a so commonly-used syntactic construct.)

[MajorBreakfast]

The current destructuring syntax isn’t very intuitive. But yes, if we changed it to use =, like my proposal has intended (didn’t explicitly say so, but it was the intention), it’d make it even worse. Maybe @Centril is right that it should be more verbose with a nice litte keyword that says what’s what? I can say from experience that the destructuring syntax with : can definitely be also very confusing.

[mpol]

For prior art we also have Haskell, which does use = in record pattern matching. See eg. https://en.wikibooks.org/wiki/Haskell/Pattern_matching#Introduction_to_records

[Centril]

For prior art we also have Haskell, which does use = in record pattern matching. See eg. https://en.wikibooks.org/wiki/Haskell/Pattern_matching#Introduction_to_records

Right! I’ve clearly not written enough Haskell lately; it is showing…

the status quo is pretty clear

Respectfully I disagree, I find any use of the type-judgemental form to be confusing when it is actually not doing typing judgments.

Perhaps the Struct { field: binding } form is not common enough that it won’t be as bad as bricking the field: stuff syntax everywhere, so it’s a much smaller delta. It might be worth a crater run to see how much would break and then introduce Struct { field @ binding } which is a much more consistent and natural syntax and then use the other form for type ascription eventually.

[H2CO3]

the type-judgemental form

You have clearly written too much Haskell lately; it is showing…

Like as, I consider the : syntax to have different meanings depending on the context. Just like for is not called “the loop syntax”, because it means a loop in statement position but a type specification inside a trait impl, I wouldn’t go so far as calling any colon-based syntax “the type judgmental form”.

Perhaps the Struct { field: binding } form is not common enough

Do you mean in patterns specifically?

[MajorBreakfast]

The @ destructuring syntax is growing on me