> > There are some people using this syntax to distinguish between array
and
> > string access. It's a nice thought, but as the vast majority of code
> > doesn't make this distinction (I think the only time I saw this in
recent
> > years was inside some old PEAR code), it's not really a useful
indicator.
> I personally use it because I like to quickly tell if I am doing an
> operation on a string or array, it is eye candy and makes a lot of
> sense. I think if anything the two syntaxes should be decoupled
> instead.
I think that suitable naming is more useful for this purpose.
As this syntax used both for arrays and strings then "$a{2}"
says absolutely nothing to anybody instead author, maybe.
> The thing is, I just don't understand the rationale to remove this
> feature, what the full gain from doing so is?
I'm fully agree with Nikita Popov:
> > > The rarity of its use also makes it rather confusing. While $foo[$x]
is well established as an
> > > array or string offset (or for that matter, ArrayObject) access and
will be
> > > recognized by any programmer coming from any number of programming
languages,
> > > $foo{$x} certainly is not, and is a WTF moment for people who don't
happen to personally
> > > use this syntax.
Furthermore, curly braces is standard way to separate scope in almost
all languages including PHP (except one very rare and special case).
@Michael Wallner
> Do I understand it right, that you're proposing deprecating accessing
> $string{$offset}? I think that's an important way of differentiation
> between string and array offset access.
>
> I'd vote "yes" for splitting syntax on array and string offset access,
> but as is: -1.
When we access char inside string, actually we access
to element of indexed array of chars.
Splitting array and string access is complex change.
For now it processed on AST-creation phase and it is possible
to transfer to compiler via AST-attribute. For splitting
it is needs to transfer this difference into runtime.
In addition, this separation can lead to much more ambiguity when
migrating old code.
