Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New option to style + in where bounds #4979

Open
Iron-E opened this issue Sep 6, 2021 · 0 comments
Open

New option to style + in where bounds #4979

Iron-E opened this issue Sep 6, 2021 · 0 comments

Comments

@Iron-E
Copy link

Iron-E commented Sep 6, 2021

Coming from #4941. In that issue I suggested that binop_separator be used to control situations such as the following:

pub async fn retrieve_views<'err, E, L, O, P>() -> DynResult<'err, Vec<EmployeeView>>
where
	<E as EmployeeAdapter>::Error: 'err
		+ From<<L as LocationAdapter>::Error>
		+ From<<O as OrganizationAdapter>::Error>
		+ From<<P as PersonAdapter>::Error>
		+ Send,
{

On the above, @calebcartwright said:

Thanks for sharing this observation but binop_separator is by design only applicable to binary expressions, and does not apply to compound constraints regardless of the fact that the latter utilizes one of the same symbols.

[…] If you'd like to have a new config option that could be used to control that behavior in bounds then please open a new issue and we'll take that through the standard process to consider new options.

…which makes sense. However, it leaves rustfmt without a way to configure how constraints are formatted, whereas there are similar options for other contexts (i.e. binop_separator). I personally think this should be configurable, as setting binop_separator to "Back" in a project leaves +-signs at the front in only this case.

I would propose that this new option have the same "Front" and "Back" values available in order to maintain a consistent style across projects.

Thanks for your consideration!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants