Re: RFC - Array slice syntactic sugar

From: Date: Fri, 20 Mar 2015 18:16:36 +0000
Subject: Re: RFC - Array slice syntactic sugar
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17  Groups: php.internals 
Request: Send a blank email to internals+get-85313@lists.php.net to get a copy of this message
Alex, On Fri, 2015-03-20, at 17:19, Alex Bowers wrote: > When you say restrict to one each. Do you mean one for strings and one for > arrays? Yes, that's what I mean. I would propose square brackets for array offsets, and curly braces for strings. > If so I'd have to disagree with this, since having the same operation > available to both is less likely to give mistakes. Can you give an example > of an actual benefit for this? Since this would cause a backwards > incompatible change. I can't imagine many places if any use the curly > brackets for arrays or strings, but since it exists there may be people > using it. Changing the behaviour of this to only work for one of the two > options seems unnecessary in the name of making code slightly more > apparent on initial reading. But variable names and so on should be used > to help distinguish from array or strings anyway. Yes, I'm very conscious of the substantial BC break, which is why I would target PHP 8 (or even 9, following a deprecation cycle). I guess you and I disagree on the benefits of syntax that is more self-documenting. The vast majority of PHP developers don't use variable names to indicate data types; the only common convention I've seen is for arrays' names to be pluralized (ie. $items, $rows etc.), but this doesn't really help. Often when less- experienced developers come across code that uses subscript syntax on a variable, they typically assume that the variable is an array (since string offsets are so much less common), and in doing so, introduce bugs. If the use of curly-braces was mandatory for string offsets, then code like this couldn't be mistaken for anything else. Vik

« previous php.internals (#85313) next »