On Wed, Apr 10, 2013 at 05:25:53PM -0700, Erick Tryzelaar wrote:
> Great! We've needed something like this. I worry a little bit about the
> function declaration style though. I could see it being difficult to
> implement this format in the pretty printer, which would make it hard to
> write something like gofix. Here's the longest function declaration I could
> find in our codebase, this one in src/librustc/middle/typeck/infer/unify.rs:
>
> fn simple_vars<T:Copy + Eq + InferStr + SimplyUnifiable, V:Copy + Eq +
> Vid + ToStr + UnifyVid<Option<T>>>(&mut self, +a_is_expected: bool, +a_id:
> V, +b_id: V) -> ures {
>
> Assuming we extended the rule to the typarams, we'd have:
>
> fn simple_vars<T:Copy + Eq + InferStr + SimplyUnifiable,
> V:Copy + Eq + Vid + ToStr + UnifyVid<Option<T>>>(&mut
> self,
>
> +a_is_expected: bool,
> +a_id:
> V,
> +b_id:
> V)
> -> ures
> {
>
> Which in my opinion is hard to read. Then there's the question of what
> happens if even after wrapping the line pushes us past the 100 character
> limit?
>
> For my bikeshed, I have started using the basic rule that if I can't fit a
> statement on one line, I wrap and indent 4 spaces after a '<', '(', or '{':
>
> fn simple_vars<
> T:Copy + Eq + InferStr + SimplyUnifiable,
> V:Copy + Eq + Vid + ToStr + UnifyVid<Option<T>>
> >(
> &mut self,
> +a_is_expected: bool,
> +a_id: V,
> +b_id: V
> ) -> ures {
I prefer this style as well, although in my experience it doesn't seem
to be very common among C/C++ programmers for whatever reason. The
benefit here over just indenting the next line without putting the
closing brace on its own line (like the next example) is that the
signature doesn't visually run into the body of the function.
> Another option is to do what Go does, and say there's no limit in the line
> length, but if the user wants to wrap, just add a tab to the start of the
> next line. So it could look something like this
>
> fn simple_vars<
> T:Copy + Eq + InferStr + SimplyUnifiable,
> V:Copy + Eq + Vid + ToStr + UnifyVid<Option<T>>>(&mut self,
> +a_is_expected: bool, +a_id: V, +b_id: V)
> -> ures {
>
> It's a little ugly, but it's consistent, and really easy to implement with
> a pretty printer. Here are the Go rules:
>
> http://golang.org/doc/effective_go.html#formatting
>
> I personally don't care what style we use, I just want to make sure we
> choose a style that's easy to automate so we can move on with our lives.
-doy
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
