pre-RFC: Leading commas

Definitely agree here.

No, unfortunately I don’t. I’d have to put some thought into it. I’d really need to check and see what the current Rustfmt options are named for formatting/styling trailing commas style.

As far as what the style should be, I think the examples you showed should be good guidance. I would, however, tend to want to prefer not having leading (or trailing) commas if it is all on one line, so, to me (opinion only, which isn’t worth much)

let (, b): (, usize) = (, 2);
// equivalent to:
let (b,): (usize,) = (2,);

let (, a, b, c): (, usize, usize, usize) =
    (
    , 42
    , 1337
    , 42
    );

Would be discouraged and instead would prefer this:

let (b): (usize) = (2);
// equivalent to:
let (b): (usize) = (2);

let (a, b, c): (usize, usize, usize) =
    (
    , 42
    , 1337
    , 42
    );

Notice, no leading/trailing commas on the one-liners above.

That being said, it wold be nice if this also were optional and could be toggled as well if the author so preferred.

1 Like

Great :+1: I’ll do the same.

It’s an opinion I share :wink: I think it is a good rule of thumb. I think usually, you don’t have a trailing comma on a single line either, so (a, b) and not (a, b,) (unless you have (a,) which you have to write that way because it is a different type than (a)).

I’ve only seen leading commas used as a workaround in places where trailing commas aren’t supported. Since Rust does support trailing commas quite well, I’m against adding an ugly hack for a non-existent problem.

7 Likes

Why is it non-existent? There are people who use leading commas and prefer it that way, and not because of a lack of trailing commas.

“Ugly hack” is also quite subjective.

A few more drawbacks:

  • looks noisy to everyone but the tiny minority
  • supporting multiple syntaxes might make parsing code more difficult, slower and more error prone for humans because of unfamiliarity
  • more lax syntax increases risk of copy-paste errors and typing mistakes to go unnoticed
  • people that are new to the language might get confused and think that this means something different, or perhaps it will annoy them so much that they lose interest in Rust
  • it will take more time to learn the language
  • there’s a greater risk that source code parsers, highlighters will fail with this unusual syntax
  • it’s easier to fail to write correct parsers for Rust which might lead to lower support for Rust syntax in editors etc.
3 Likes

I’d be fine with relaxed syntax where it makes sense from a technical perspective, e.g. keeping diffs trim or helping macro expansion, but this proposal adds nothing on that front. Indeed, it makes it harder to write macros that accept a list of things. (Remember that some core macros didn’t accept trailing commas until recently.)

Instead, it caters to the preference of a small group, with little to no prior art in other languages.

6 Likes

I think there is a lack of strong motivation for this at the moment. Also, I think a number of the motivation points are misleading:

It is in line with Rust’s philosophy to have a tolerant grammar

I think this is not an argument for adding syntax which does nothing, rather it is an argument to allow such syntax when there is a strong motivation. It’s not motivation in and of itself (It’s easy to come up with syntax extensions that are utterly pointless, but allow more valid programs.)

Clean diffs

No cleaner than trailing commas, surely?

Easier multi-cursor support

Again, as long as you have either trailing comma or leading comma support, this is easy. You don’t gain any benefit from editors from adding both.

JavaScript

JavaScript is not prior art. JavaScript does not allow leading commas with no semantic value. An “empty array element” is treated as undefined. This is entirely different from what this pre-RFC is proposing. (JavaScript does have proper trailing commas, however.)

The main advantage to such a feature is for people who prefer leading comma style. I really can’t imagine such an opinion is shared among very many people at all. If this is not advantageous to a significant group of people, the disadvantages (as mentioned by others previously in the thread) would seem to me to outweigh the advantages considerably. If you’re putting this forward as a “some people prefer this style”, could you provide concrete examples? (Even just a few people posting in this thread would be enough to satisfy me.)

1 Like

Assuming the macro wants to support the format. But I will elaborate on this in the drawbacks.

I think this falls under “Some people will not want to read this in the code of others”; I’ll elaborate on it in the drawbacks;

Sure; That is “It complicates the grammar”; But I doubt it will have any noticable perf impact; all the compiler has to do is to check for a comma in front, eat it and then continue as before.

Elaborate on how this applies / example?

Somehow this sounds artificial to me. And people who don’t use the style can’t be annoyed with it; the only way they can be annoyed is if they read someone else’s code; which I’ve already written about in the drawbacks.

It will take more time to learn all the valid forms of the grammar, yes - but you don’t need to learn every strange syntactic form to make you proficient at using Rust. But I’ll include this

Sure; parsers always have to be updated when the grammar of a language changes. However, as you can see from the highlighting above, the highlighter for the internals forum already handles this well, and so did VSCode. So there is a risk that some work will be required, but I’d say it is low and the work needed is also low.

For the linked RFC, it seemed sufficient motivation that a minority of people preferred this style. In fact, the quote says that there needs to be strong practical motivations not to do this (ambiguities, slower parsing (and not by a millisecond)).

Yes, as already mentioned in the motivation they have equally clean diffs.

Already mentioned.

This is also noted (the length comparison) but I will clarify this.

Myself and @ExpHP as per the quote in the Prior Art.

As far as I’ve seen, this is the preferred style of match statements in OCaml — even if, in Rust, this pattern made up a minority, there is clear precedence in a very similar language construct in another popular language.

This doesn’t seem to be a motivation, then. You don’t get cleaner diffs, or ease of use after this RFC that you wouldn’t already have. So there’s no advantage (just no disadvantage when it comes to these particular qualities).

Regardless of how you phrase it, I think this is misleading as it is an entirely different feature. It just looks syntactically similar — but the semantics are different, which surely makes it irrelevant.

Maybe it would be a good idea to hold a poll or something to see which style people prefer. I’d feel more comfortable knowing there was a reasonable proportion that preferred this. (Leading | in match has strong precedence in languages like OCaml, but I haven’t seen a similar effect for leading commas in other similar languages).

I’ve updated the pre-RFC now to address your comments as nuanced as I could.

Fair enough; I moved those parts to the rationale.

Removed the section accordingly.

Linking what I said last time: Grammar liberalizations

I see no good reason to do this (in contrast to the vert change), as this is a ton of churn and doesn’t actually make any scenarios easier over just using what’s already supported.

(Also, if this is accepted, I don’t think it’s just about commas, and should also allow trailing verts, leading +, etc as well.)

Not really; we just allow ; as short form for ();;bar() ;bar() is different from bar(); bar(); in general.

1 Like

@varkor And here’s the poll you requested =)

  • I would use leading commas.
  • I would not use leading commas.
  • I would not use leading commas, but I don’t mind it either.

0 voters

If we were doing this, wouldn’t it be strictly better to support “•” (Unicode 2022) as the leading separator, since that’s the correct symbol to use for an unordered list, instead of incorrectly abusing the comma?

Or no punctuation at all, which is also a reasonable style.

1 Like

I would do that but I don't have that symbol on my keyboard :wink:

Not just some - most probably. And for what reason? The burden of motivation should be on the part introducing new syntax not the other way round.

I’m not talking about compilers but human readers. I experienced great difficulties when trying to read your examples. The spacings, alignments and groupings all seemed very off to what I’m used to. Not only did it take more time to read this for me, I’d easily make mistakes or fail to catch mistakes because of the unfamiliarity.

If you make a copy-paste error, for example fail to copy an element but only its comma this would still be valid. You might also plan to change the first item in a list, erase it but forget to write its replacement. The acceptance of the leading comma will not signify that an error was made.

That’s not true at all. Code on forums, in blog posts, in libraries, on github… It’s not possible to run rustfmt on all of that. You would have to deal with it. It puts an unnecessary burden on those who are just trying to learn or understand. It adds more friction on forums and in teams working together for no increase in expressiveness of the language. There are reasons standards exist after all.

You need to learn this to read Rust code. The language is already huge and takes a lot of time to learn. Opening the flood gates by accepting all kinds of creative styles is hardly a good idea, other than if the goal is to make Rust look like an unrestricted art spectacle.

Yes, but this means more work for a lot of people. Each of them will have to implement this unusual syntax. We’re not just talking about VSCode. Every single implementer that aspires to support Rust will have to deal with this oddity. Mistakes will be embarrassing. Apart from highlighters these mistakes might have more serious consequences.

In conclusion, energy, money and time will be wasted that could otherwise be used to solve real problems.

3 Likes

The leading commas thing is common in MS SQL. When it auto-generates SQL queries etc (in SSMS - SQL Server Management Studio etc), it, by default, uses the leading comma convention. So, there is at least some small amount of prior art. Also, as the OP mentioned, it is common in Haskell to use the leading comma convention, so, I’m not so sure the “No prior art” argument is as absolute as implied.

That being said, as I previously mentioned, I’m not particularly a fan of the leading comma convention and would be happier if it were not supported in Rust, but, I can think of no good reason (beyond personal preference) not to support it.

@repax I think your points are well argued and made :+1: . They are I think sufficient for me to say: “OK, let’s not do this” even tho I would prefer to use the syntax personally.

I would like to thank all of you for the time you spent discussing this with me. :heart:

7 Likes

Independent of the pros and cons of leading commas (which I do think make good pseudo-bullets), one of your examples in the pre-RFC (first post of this thread) is incorrect. You wrote

let (, a, b, c): (, usize, usize, usize) =
    (
    , 42
    , 1337
    , 42
    );
// equivalent to:
let (a, b, c): (usize, usize, usize) = (1, 2, 3);

I believe most readers would think it equivalent to

let (a, b, c): (usize, usize, usize) = (42, 1337, 42);
2 Likes

Oops :wink:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.