Hey #PHP. When you use union and intersection types, do you include spaces?

(RT for reach, etc. This is survey data for @phpfig. If you know of any official policies by major projects already, please note/link in the replies.)

#codingstyle #phpfig

Foo|Bar, Foo&Bar, (Foo&Bar)|Baz
59.4%
Foo | Bar, Foo & Bar, (Foo & Bar) | Baz
39.6%
Other (specify)
1%
Poll ended at .

@Crell @phpfig for everything that has more than a simple & or | chain having spaces is such an accessible thing for me, allowing me to parse the blob of symbols.

If my editor would highlight the braces and symbols differently from the text I would have more of a chance without spaces, but as it is, it's very annoying. Especially because they need to restate the compound types everywhere, not just define them once like in TS.

@edorian @phpfig So it depends on how complex it is?

Foo|Bar|Baz is OK, but not if mixing and &?

@Crell @phpfig For me, somehow yes.

If there are no braces I know at the first symbol that it's a uniform list and that I can just go and skip-scan through the text.

But (ClassNameWithSomeLength|(Foo|Bar))&Baz type constructions are quite hard for me to parse visually.

Might be the |( and &( constructions. Unclear t.b.h., just noticed it's more of a strain.

Given how rarely such complex types happen I'm going to be fine either way :)

@edorian @Crell @phpfig

> But (ClassNameWithSomeLength|(Foo|Bar))&Baz type constructions are quite hard for me to parse visually.

That is incorrect syntax, because that's not in DNF 😃 (only & may appear within the parentheses). Parentheses may also not be nested.

Thus the only legal variants are:

- A|B|C
- A&B&C
- (A&B)|C|D

@edorian @Crell @phpfig

> having spaces is such an accessible thing for me, allowing me to parse the blob of symbols

For me it's the other way around: No spaces, please.

Without spaces the type visually appears as a single token and when seeing the space I know the variable name comes next. For me the variable name is the most important piece of information.