-
Notifications
You must be signed in to change notification settings - Fork 27
3.0 changelog #116
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
3.0 changelog #116
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could benefit from an illustrative snippet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm, nice work 👍🏼
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.