On Wed, Aug 19, 2020 at 11:13 AM Michael Voříšek - ČVUT FEL < voris...@fel.cvut.cz> wrote:
> Please add discussion about merge conflicts. Any inline grouped > attribute syntax needs a manual conflict resolution. > > With ungrouped syntax, I expect recommended CS to be one attribute per > line. > This is discussed under grouping already. It is a coding style issue, so it's not really relevant as you can use all the syntaxes in an ungrouped mode if you are concerned about conflicts. > If this should be the case also for grouped syntax, then it not +1 > character, but +2 new lines per every annotated element. > > Also, is 2/3 majority required by RFC rules satisfied by the "Are you > okay with re-voting on the attribute syntax for PHP 8.0, again?" > question? > I think we should require 2/3 votes at least on the question if we > should allow grouping or not and if accepted, use STV results on the > prefered prefix symbols/syntax. > Yes, that was exactly the same type of vote for "shorter attribute syntax" RFC. > > With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem, > > Michael Voříšek > > On 19 Aug 2020 10:47, Benjamin Eberlei wrote: > > > On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei <kont...@beberlei.de> > > wrote: > > > > On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans <der...@php.net> wrote: > > > > Hi, > > > > Out of Banjamin's suggestion[1 [1]], I've updated the Shorter Attribute > > Syntax Change RFC to reflect that process: > > > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > > > Patches and comments welcome. > > > > FWIW, this has an excemption from the RM Sara as per [2 [2]]: > > > > * Shorter Attribute Syntax Change > > - Joe/Derick - Please make sure this RFC moves along and reaches > > conclusion by beta3, as discussed previously. > > Heads up: This RFC is now going to vote tomorrow: > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > I have updated the RFC one last time with as much of the feedback as > possible: > > - a section about comparing to complexity of type definitions > - removal of the machine reading section as too narrow and ultimately > not > that important as downstream libraries just have to deal with any of it > - some more nuances in forward compatibility pro/cons section of #[] > - smaller corrections and improvements. > > I don't think something major is missing now. > > One last change that I didn't see yesterday as it was on Github and not > this list is the addition of another syntax proposal @{} with the same > benefits as @[], a little more snowflake than compared to other > languages, > but without the BC Break. > > >> cheers, > >> Derick > >> > >> [1] https://externals.io/message/111218#111261 > >> [2] https://externals.io/message/111286#111286 > >> > >> -- > >> PHP 7.4 Release Manager > >> Host of PHP Internals News: https://phpinternals.news > >> Like Xdebug? Consider supporting me: https://xdebug.org/support > >> https://derickrethans.nl | https://xdebug.org | https://dram.io > >> twitter: @derickr and @xdebug > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: https://www.php.net/unsub.php > > > Links: > ------ > [1] https://externals.io/message/111218#111261 > [2] https://externals.io/message/111286#111286
