Re: deprecation status of $str{42} versus $str[42], revisited

On 22 September 2010 22:34, Philip Olson <philip@roshambo.org> wrote: > Greetings geeks, > > This topic still lacks a defined conclusion. There are several rumors that something was > decided, but I can't confirm this without archived proof. Here's the code: > >  $str = "I am an array of characters, but still a string."; > >  echo $str[3]; // Documented as correct since 2006 >  echo $str{3}; // Documented as deprecated since 2006, but still no E_DEPRECATED error > > We discussed this uninteresting topic back in 2008 here, which includes the timeline: > >  - http://php.markmail.org/thread/nm7n57ns23mwoshw > > There was no conclusion, and the thread went off topic. So because code speaks louder than > words, the following will happen if this does not receive an alternative conclusion here: > >  - Both will be considered fine, where neither is deprecated. Both will be documented as > proper. For no real, technical, reason, (just what my gut wants, and I tend to listen to it) I would prefer both to continue being equal* without any deprecation (E_DEPRECATED or just word-of-mouth). * They're not always interchangeable: this may be sliding off-topic (so feel free not to address it in this thread) but I'd quite like the curly-brace syntax to be available for the function array dereferencing which was added to trunk if only to keep things consistent. > > One opinion is it should remain deprecated but without an E_DEPRECATED error, but I'm > unsure how that makes sense. To me that says it's not deprecated, but rather, is discouraged > (but still for unknown reasons). Anyway, thoughts? > > Also, Andi mentioned[1] the possibility of optimizing {} for string use (the original intent) > in which case keeping {} would be wise. > > [1] http://markmail.org/message/qisqdheeyoccfydh > [2] Related bug: http://bugs.php.net/52254 > > Regards, > Philip > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >