-
Notifications
You must be signed in to change notification settings - Fork 56
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
type aliases #32
Comments
// generally
type X /* <- one line */ = Foo;
// need to break
type LongName = /* <- don't break here */
FooBar; /* <- pull this down */ |
Pretty simple one, I think, ready for FCP. |
Questions: If there is a where clause, should we leave on one line, e.g.,
I propose not, since that is what we agreed for where clauses in general. In which case how should we break this?
Would be my suggestion, the only downside is that we had previously decided to break after the And to check - trailing comma here is OK? |
@nrc Type aliases with where clauses seem like a sufficiently different case to be worth evaluating separately from functions with where clauses. And they have kind of an awful order of terms, which we can't do anything about. I think I'd argue that in the majority of cases type aliases should inline the constraints inside the I don't think we should change the decision to break after the |
Again, I'd like to discuss generics separately (#29), so that should make this one pretty trivial.
The text was updated successfully, but these errors were encountered: