Skip to content

newtypes are formatted on two lines with break_single_constructors: false #342

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

Open
imuli opened this issue Nov 27, 2020 · 6 comments
Open

Comments

@imuli
Copy link
Contributor

imuli commented Nov 27, 2020

As newtypes always have a single constructor, you would think that they
would obey break_single_constructors. However, with that set to false,

newtype Foo = Foo Int

becomes

newtype Foo
   = Foo Int

while data with a single constructor stay on one line.

data Foo = Foo Int
@imuli imuli changed the title newtypes are formatted on two lines with break_single_constructors: false newtypes are formatted on two lines with break_single_constructors: false Nov 27, 2020
@imuli
Copy link
Contributor Author

imuli commented Nov 27, 2020

Okay, having now found the place in the source that explicitly checks this and the test case that claims the current behavior is correct, it seems like @jaspervdj wants this behavior. I still find it unintuitive - if it's not too much configuration bloat could we add a break_newtypes flag?

imuli added a commit to imuli/stylish-haskell that referenced this issue Nov 27, 2020
Default behavior remains the same, but when you set `break_newtypes` to
`false` newtypes will be formatted on a single line.
@EncodePanda
Copy link
Contributor

EncodePanda commented Apr 9, 2021

I think this accident @imuli . newtype and data have to be consistent. let's fix that.

@stevladimir
Copy link

Hello, any progress on that? Maybe I can help somehow?

@jaspervdj
Copy link
Member

Yeah this is accidental. I would welcome a PR that fixes this :-)

@stevladimir
Copy link

stevladimir commented May 30, 2022

IMO this should be the default behavior, but it is somewhat breaking change (people might get big diffs) if we just directly alter the current behavior. If this is acceptable I would go this way as I see no strong reasons to distinguish newtype and data in this respect.

Otherwise, @imuli has a fix which should be backwards compatible in cost of introducing a new option.

Which one would you prefer?

@imuli
Copy link
Contributor Author

imuli commented May 30, 2022

I think the primary issue with my fix as it stands is that it doesn't provide any tests?

I also would have no complaints about somone removing the option in favor of break_single_constructors.

imuli added a commit to imuli/stylish-haskell that referenced this issue Sep 2, 2022
Default behavior remains the same, but when you set `break_newtypes` to
`false` newtypes will be formatted on a single line.
imuli added a commit to common-edge/stylish-haskell that referenced this issue Mar 5, 2023
Default behavior remains the same, but when you set `break_newtypes` to
`false` newtypes will be formatted on a single line.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants