Conversation
| Formatting conventions are now provided for compound types (those that include union or intersection type declarations). | ||
|
|
||
| * The `|` and `&` symbols and parentheses MUST NOT have leading or trailing spaces. | ||
| * If a type declaration is long enough to split to multiple lines, each ANDed block must be on one line, and each ORed block on its own line. |
There was a problem hiding this comment.
| * If a type declaration is long enough to split to multiple lines, each ANDed block must be on one line, and each ORed block on its own line. | |
| * If a type declaration is long enough to split to multiple lines, each block must be on one line, and each block on its own line. |
There was a problem hiding this comment.
I'm not sure this is clear for what it implies. There's 2 different kinds of blocks, so it's not clear what this version is saying.
There was a problem hiding this comment.
Could benefit from an illustrative snippet.
There was a problem hiding this comment.
There may be a misunderstanding on my part with this suggestion.
The original texts says: [...] each ANDed bock must [...] and [...] and each ORed block on [...].
I thought it was a typo, and removing these two words from the text (ANDed & ORed) makes sense.
If it is the case that these words are specific blocks or something, all good 👍
Co-authored-by: Juliette <663378+jrfnl@users.noreply.github.com>
|
Just out of curiosity, is there an ETA for the new 3.0 PER version on the web? :) |
|
When the CC is finished voting: https://groups.google.com/g/php-fig/c/p3TET3uDAgw/m/p9AbDkSRBQAJ |
|
Fixed! |
|
Thanks for this release! The migration guide lists the following under section 4.3:
However, I'm unable to find anything related to class constant types being required in the spec. Was this an oversight in the spec or in the migration guide? |

The links point to the live site, like the 2.0 changelog does, so not all of them will work yet. They should once it's tagged and published, though.