On Fri, Jan 17, 2020 at 3:58 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > On 2020-Jan-16, Tom Lane wrote: > >> ... But I was hoping to > >> hear Piotr's opinion before moving forward.
Me too. Thinking about this again: It's obviously not true that everything that looks like a function call is not a cast. You could have "my_cast(Type)" that expands to "(Type)" or some slightly more useful variant of that, and then "my_cast(Type) -1" would, with this patch applied, be reformatted as "my_cast(Type) - 1" because it'd err on the side of thinking that the expression produces a value and therefore the minus sign must be a binary operator that needs whitespace on both sides, and that'd be wrong. However, it seems to me that macros that expand to raw cast syntax (and I mean just "(Type)", not a complete cast including the value to be cast, like "((Type) (x))") must be rare and unusual things, and I think it's better to err on the side of thinking that function-like macros are values, not casts. That's all the change does, and fortunately the authors of indent showed how to do that with their existing special cases for offsetof and sizeof; I'm just extending that treatment to any identifier. Is there some other case I'm not thinking of that is confused by the change? I'm sure you could contrive something it screws up, but my question is about real code that people would actually write. Piotr, is there an easy way to reindent some large non-PostgreSQL body of code that uses a cousin of this code to see if it gets better or worse with the change?
