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

[unstable option] space_before_colon #3365

Open
scampi opened this issue Feb 13, 2019 · 3 comments
Open

[unstable option] space_before_colon #3365

scampi opened this issue Feb 13, 2019 · 3 comments
Labels
unstable option tracking issue of an unstable option

Comments

@scampi
Copy link
Contributor

scampi commented Feb 13, 2019

Tracking issue for unstable option: space_before_colon

@scampi scampi added the unstable option tracking issue of an unstable option label Feb 13, 2019
@scampi scampi changed the title [unstable option] unstable option: space_before_colon [unstable option] space_before_colon Feb 18, 2019
@lucidBrot
Copy link

(Please excuse if this does not belong here)

Is there a way (planned) to distinguish between a parameter list, let statement, and other uses of the type annotation colon?

I would like to have my code formatted so that

let my_string : String = "hello".to_string();

has a space before the colon, because the colon feels like it separates the type from the identifier.
But I would like to have no space before the colon here:

fn foo( my_arg: String, another_arg: &str) {

}

because the type belongs to its preceeding argument and it feels like it is too close to the next parameter when I have the space before the colon.

Of course, tastes may vary. And it's not that important to be able to distinguish these cases. But I'd like to, if it was easily doable.

@anordal
Copy link

anordal commented Feb 22, 2020

My thoughts as well, but to say it in one rule: The colon belongs with the type when the type is optional. Because they are added or removed together. Just like in UML.

I can think of 3 uses of colon:

  • Before an optional type (those let statements)
  • Before an obligatory type (such as function and struct parameters)
  • Before a value (in designated initializers)

I would also remove the space after the colon (#3366) by the exact same rule, but maybe that's just me.

@effinsky
Copy link

effinsky commented Jan 29, 2024

I just think it looks more readable with the space before the colon across the board. ML-heritage showing 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unstable option tracking issue of an unstable option
Projects
None yet
Development

No branches or pull requests

4 participants