rfc:deprecate_curly_braces_array_access

This is an old revision of the document!


PHP RFC: Deprecate curly braces syntax for accessing array element and string offset.

Introduction

Both square brackets and curly braces can be used interchangeably for accessing array elements (e.g. $array[42] and $array{42} will both do the same thing in the example above).

Proposal

Deprecate curly braces syntax for accessing array element and string offset.

Reasons to deprecate curly braces syntax::

  1. Two ways to do the same thing.
  2. It is very rarely used nowadays.
  3. It is almost not documented. There is only two short “NOTE” about it.
  4. Also, this syntax has reduced functionality. You can't use it for pushing element into array “$arr{} = 1;”, creating array “$a={1,2};” or in other similar cases.
  5. Deprecation and following removal will free this syntax for other features. For example: array/string slice, absolute offset access, “windows” (like “slice” in GoLang), etc.
  6. Furthermore, curly braces is standard way to separate scope in almost all languages including PHP (except one very rare and special case).

<?php
$arr=[1,2,3];
 
var_dump($arr{1});

Output

Warning: Array and string offset access syntax with curly braces is deprecated in /root/php-src/1.php on line 4
int(2)

Discussion

Disagree

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.

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.

From a usage PoV, then from personal experience (outside my own projects), I have seen many usages of this syntax, even as late as my current company with a growing codebase that is nearing 1.1m LoC, I have seen this syntax used countless of times. In fact I don't think I have been working with a code base where I have not seen this syntax used.

I have asked fellow developers around in my community today and they have no strong opinion on either, but do like the distinction between.

Agree

I'm okay with this. This syntax has already been deprecated once, though it was reverted for reasons I don't remember.

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. 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.

I'd prefer to phase out this syntax entirely and not reuse it for any other purpose. Reusing syntax is generally a not so good idea, because it means that the same syntax has different meaning in different PHP version.

Four thoughts:

1. I cannot think of any reason to separate them. If you want to make sure you are indexing a string, do a type check, not bake {} into only working on strings.

2. While Kalle says pretty much every codebase they've seen lately has used {} for indexing, I have never seen a codebase that used it.

3. In any case, usage of {} can be migrated to [] by a style fixer, right?

4. Even if we deprecate {}, I don't think we'd be in any hurry to remove it, though with an automatic fixer this seems doable, if we care to do it at all.

Backward Incompatible Changes

Yes.

Proposed PHP Version(s)

PHP 7.4

Future Scope

Change to E_COMPILE_ERROR in PHP 8.0. Remove in PHP 8.1.

Voting

2/3 majority will be required.

Patches and Tests

rfc/deprecate_curly_braces_array_access.1553503795.txt.gz · Last modified: 2019/03/25 08:49 by rjhdby