-
Notifications
You must be signed in to change notification settings - Fork 34
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
Prefer where {T}
to where T
?
#69
Comments
My personal preference when writing code is no braces for long-form functions with a single typevar, and braces otherwise. But for the purposes of this decision, I vote Option (1). Also Option (2) would lead to some cases I consider unfortunate: Option 1:
Option 2:
I don't know anyone who uses the latter form in that scenario. |
I typically use Option (3) which is to prefer braces but exclude braces when only defining a single type parameter. |
To clarify this would be: # Yes
f(x::T) where T = ...
# No
f(x::T) where {T} = ... # Yes
f(x::T) where T<:Integer = ...
# No
f(x::T) where {T<:Integer} = ... # Yes
f(x::T, y::S) where {T,S} = ...
# No
f(x::T, y::S) where T where S = ... (where the guidance is the same for both short-form and long-form functions) |
I wouldn't say using curly braces all the time is wrong just not preferred: # Yes
f(x::T) where T = ...
# Ok
f(x::T) where {T} = ... # Yes
f(x::T) where T<:Integer = ...
# Ok
f(x::T) where {T<:Integer} = ... # Yes
f(x::T, y::S) where {T,S} = ...
# No
f(x::T, y::S) where T where S = ... |
As far as i can am aware, BlueStyle has no opinion on this.
even the example code in this style guide itself is inconsistent, sometimes using
where {T}
and othertimeswhere T
(orwhere {T <: Int}
and othertimeswhere T <: Int
).We could stick with having no preference, however, for the sake of running a formatter (domluna/JuliaFormatter.jl#283, #7 ), what should a formatter do?
We have four options (to my mind, anyway)
where {T}
towhere T
where T
towhere {T}
(when valid)Option (4) is "do nothing". This isn't a great option for 2 reasons: (1) stylistically, we probably want a code-base to be consistent on this, it's one thing to say "either is fine", and another to say "both is fine". (2) effort-wise, the formatter can/does already fix these cases, so i see no reason to add functionality to leave a code-base less consistent.
I see no reason to come up with a subtle rule here (we've survived without it so far), so let's not do option (3), which is the most complicated.
This leaves options (1) and (2). Since we have no strong preference here (based on the current style guide), i say we stick with the decision made in domluna/JuliaFormatter.jl#53 and go with option (1) -- it's the more common pattern in Julia Base, and it's what JuliaFormatter does right now -- so for the sake of the formatter, prefer
where {T}
towhere T
.The text was updated successfully, but these errors were encountered: