[unstable option] brace_style

[scampi]

Tracking issue for unstable option: brace_style

[misos1]

Seems brace_style = "AlwaysNextLine" does not work on unsafe blocks.

[Sibz]

Seems brace_style = "AlwaysNextLine" does not work on logic blocks either.

[calebcartwright]

@Sibz could you elaborate on what you mean by logic blocks, with a code snippet? If you're referring to things like if, else etc. then you'll want to check out the control_brace_style option https://rust-lang.github.io/rustfmt/?version=master&search=#control_brace_style

[Sibz]

Thank you, didn't see that one and I did scour the whole list! Mustn't have had my morning coffee.

[Sibz]

New structs aren't included in this
i.e.

let value = MyStruct {
    something: 1
}

vs

let value = MyStruct
{
    something: 1
}

[Iron-E]

Closures are also not included in this.

foo.ok_or_else(|| {
  // closure
})

Should be:

foo.ok_or_else(|| 
{
  // closure
})

[Iron-E]

Sorry for double comment. Also does not work for macro_rules!:

macro_rules! filter_map_view {
  ($query:ident, $val:ident) => {

Should be:

macro_rules! filter_map_view 
{
  ($query:ident, $val:ident) => 
  {

[benaryorg]

Also doesn't work for use.

Input

Using brace_style = "AlwaysNextLine":

use ::
{
	std::time::Duration,
	async_std::
	{
		fs::remove_file,
		path::Path,
		task,
	},
	clap::
	{
		app_from_crate,
		crate_authors,
		crate_description,
		crate_name,
		crate_version,
		Arg,
	},
	log::
	{
		error,
		info,
	},
};

Expected

No changes.

Actual Result

use ::{
	async_std::{
		fs::remove_file,
		path::Path,
		task,
	},
	clap::{
		app_from_crate,
		crate_authors,
		crate_description,
		crate_name,
		crate_version,
		Arg,
	},
	log::{
		error,
		info,
	},
	std::time::Duration,
};

[calebcartwright]

At this point I think it's worth pausing to reconsider whether the current option is the right approach to meet the needs of users. For reference, this option was historically only applied to items; not in the expression nor statement contexts. control_brace_style also exists to configure the brace style on control flow type expressions.

We'd started extending the option to cover a few additional expression contexts, such as on unsafe, async, and extern blocks. However, I'm increasingly getting the sense that having only one option (essentially) is unlikely to provide a sufficient amount of flexibility. I wonder if instead we might need to a tiered approach that provide more options with more granular control, as well as a top level "big hammer" option that cascades everywhere unless overridden by a more granular one (similar to the width heuristic options). For example, while some folks may want every brace to always be on its own line everywhere, others may indeed just want the style to apply to items and not say the bodies of their multiline match arms.

This option as originally intended and implemented, controlling brace style for items, is actually probably a fair candidate for stabilization at this point, but if we need to extend it out to cover every expression context as well then it's likely to remain unstable for years to come.