[unstable option] comment_width

[scampi]

trafficstars

Tracking issue for unstable option: comment_width

[carols10cents]

Not sure if this is the right place to add this comment or not; feel free to tell me to go somewhere else.

I was surprised to find out that the default value for comment_width is 80, while the default value for max_width is 100. I would have expected the defaults to be the same.

So before comment_width is stabilized, I'd like to advocate for reconsidering the default value.

Do text editors display/enforce different widths for comments vs code? I use TextMate, and it just has one wrap column setting.

Examples:

What looks "good" to me:

// This line of code is just about width 100
fn evaluate_something_test(something: &Something, number: usize) -> Result<BTreeMap, CustomError> {
    // This comment is wrapped to 100. Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed 
    // do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis 
    // nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute...
    unimplemented!();
    
    // This is what I would expect. irure dolor in reprehenderit in voluptate velit esse cillum 
    // dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in 
    // culpa qui officia deserunt mollit anim id est laborum.
}

What looks "strange" to me:

// This line of code is just about width 100
fn evaluate_something_test(something: &Something, number: usize) -> Result<BTreeMap, CustomError> {
    // This comment is wrapped to 80. Lorem ipsum dolor sit amet, consectetur 
    // adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore 
    // magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation 
    // ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute...
    unimplemented!();
    
    // This looks strange to me. irure dolor in reprehenderit in voluptate 
    // velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint 
    // occaecat cupidatat non proident, sunt in culpa qui officia deserunt 
    // mollit anim id est laborum.
}

[calebcartwright]

will add explicitly, and more verbosely, that I'd prefer to see the default for this option be the same value as max_width as well. AFACIT the default value of 80 for this was established way back in 2015 in a rather ad-hoc manner during the earliest days of rustfmt development, and it seems to have continued on being the default ever since without any explicit discussion and reasoning around why it is less than max_width (at least none that I could find, though happy to be proven wrong).

[tgross35]

Would it be possible to default to whatever max_width is, instead of having a fixed default value?

I'm thinking that in most cases, anybody who changes max_width would probably want comment_width to change with it. Then explicitly setting comment_width would override that if needed

[c-git]

I remember looking up what the problem with stabilizing this was. But I can't remember where to find it. Can someone point me in the right direction please.

Since I'm commenting I'll just add a +1 for the single setting to max_width possibly with override as mentioned by tgross35 (Unless there is some reason why this is more complicated than it would seem).

[calebcartwright]

Would it be possible to default to whatever max_width is, instead of having a fixed default value?

Yes, there's a number of width related options implemented this way

I remember looking up what the problem with stabilizing this was. But I can't remember where to find it. Can someone point me in the right direction please.

More generally, see #5365 #5367

In this particular case, there's a salient, unresolved question of what the default value should be.

It's a question on the Style Team's radar as well, but full disclosure, I do not anticipate this is an option that'll be stabilized in the immediate future (i.e. I'd be surprised if this is done by year end, but suspect it will be by the time the 2024 edition drops)

[c-git]

Thank you appreciate the links. I wasn't sure where to look for them.

[gilescope]

What's the current default value when I run cargo fmt on stable? (is it to not alter the comment width or to alter it to a fixed width?). Regardless there's already a default in stable (whether we like that default or not is another question); I would argue it shouldn't hold up stabilizing the mechanism for overriding that default.

[calebcartwright]

What's the current default value when I run cargo fmt on stable?

The current default is 80 https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#comment_width

However, rustfmt doesn't format comments on stable, so this option isn't operative on stable

The description of the option is:

Maximum length of comments. No effect unless wrap_comments = true.

But wrap_comments itself is also unstable and requires nightly because comment formatting is still unstable https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#wrap_comments

I would argue it shouldn't hold up stabilizing the mechanism for overriding that default.

I understand where you're coming from with this argument, but the default value for a config option (regardless of whether the option is a boolean, numeric, etc. type) is a critical factor and part of the long established process for stabilizing options.

Whether there could or should be changes to that process is fair topic for discussion, but so long as that is the process then that's what will be followed for all options, including this one.

(edit: clarified answer as I'd originally missed the "on stable" suffix of the question)