rfc:foreach-non-scalar-keys

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:foreach-non-scalar-keys [2013/02/19 12:47] – update nikicrfc:foreach-non-scalar-keys [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
-====== Allow Non-Scalar Keys ======+====== Allow non-scalar keys in ''foreach'' ======
   * version 1.0   * version 1.0
   * Date: 2013-01-28   * Date: 2013-01-28
   * Authors: Levi Morrison <levim@php.net>, Nikita Popov <nikic@php.net>   * Authors: Levi Morrison <levim@php.net>, Nikita Popov <nikic@php.net>
-  * Status: Under Discussion+  * Status: Implemented in PHP 5.5 ([[https://github.com/php/php-src/commit/fcc6611de9054327441786e52444b5f8eecdd525|commit]])
  
 ===== Current situation ===== ===== Current situation =====
Line 47: Line 47:
 These are just two examples from core classes, but it obviously also applies in many other cases (and now that we have generators, it will probably become an even larger issue). These are just two examples from core classes, but it obviously also applies in many other cases (and now that we have generators, it will probably become an even larger issue).
  
-Another key issue is that you can't really work around this generically. If you want to write code that is also compatible with ''Iterator''s that return array/object keys, you can no longer use the ''foreach ($it as $k => $v)'' syntax. You are forced to use ''foreach ($it as $v) { $k = $it->key(); ... }'', but this will obviously only with with ''Iterator''s and not with aggregates, ''Traversable''s or normal arrays. In order to properly support all use cases you'd have to wrap everything in iterators (i.e. make extensive use of ''IteratorIterator'' and ''ArrayIterator''), which obviously is an option, but cumbersome to a degree that nobody does it. What this means is that iterators like ''MultipleIterator'' are to a large part excluded from use in iterator chaining/pipelines (which is probably the most important thing about using iterators).+Another key issue is that you can't really work around this generically. If you want to write code that is also compatible with ''Iterator''s that return array/object keys, you can no longer use the ''foreach ($it as $k => $v)'' syntax. You are forced to use ''%%foreach ($it as $v) { $k = $it->key(); ... }%%'', but this will obviously only with with ''Iterator''s and not with aggregates, ''Traversable''s or normal arrays. In order to properly support all use cases you'd have to wrap everything in iterators (i.e. make extensive use of ''IteratorIterator'' and ''ArrayIterator''), which obviously is an option, but cumbersome to a degree that nobody does it. What this means is that iterators like ''MultipleIterator'' are to a large part excluded from use in iterator chaining/pipelines (which is probably the most important thing about using iterators).
  
 ===== Suggested fix ===== ===== Suggested fix =====
Line 53: Line 53:
 This RFC proposes to lift the restriction and allow values of arbitrary types to be used as keys (in particularly allowing also arrays and objects) in iterators. (Note: This proposal does not suggest allowing those key types in arrays. This is only about ''Iterator''s.) This RFC proposes to lift the restriction and allow values of arbitrary types to be used as keys (in particularly allowing also arrays and objects) in iterators. (Note: This proposal does not suggest allowing those key types in arrays. This is only about ''Iterator''s.)
  
-In order to remove this restriction the internal [[''zend_object_iterator_funcs''|http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_iterators.h#31]] API has to be changed:+In order to remove this restriction the internal [[http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_iterators.h#31|''zend_object_iterator_funcs'']] API has to be changed:
  
 <code c> <code c>
Line 59: Line 59:
 int (*get_current_key)(zend_object_iterator *iter, char **str_key, uint *str_key_len, ulong *int_key TSRMLS_DC); int (*get_current_key)(zend_object_iterator *iter, char **str_key, uint *str_key_len, ulong *int_key TSRMLS_DC);
 // Is replaced with this entry: // Is replaced with this entry:
-zval *(*get_current_key)(zend_object_iterator *iter TSRMLS_DC);+void (*get_current_key)(zend_object_iterator *iter, zval *key TSRMLS_DC);
 </code> </code>
  
-The handler will return a ''zval*'' with already increased refcount. The ''zval*'' may not be ''NULL'', unless an exception was thrown.+The handler has to write into the passed ''zval*'' using one of the ''ZVAL_*'' macros.
  
-The signature can use ''zval*'' instead of ''zval**'' because by-ref modification of keys is not possible. The refcount is increased in the handler (instead of the VM) as that turned out to be the more convenient method for this use case.+===== iterator_to_array() ===== 
 + 
 +When using non-string/int keys ''iterator_to_array'' with the ''$preserve_keys'' option will behave in the same way as PHP would when it does normal array key assignments, i.e. its behavior would be the same as the following PHP snippet: 
 + 
 +<code php> 
 +function iterator_to_array($iter) { 
 +    foreach ($iter as $k => $v) { 
 +        $array[$k] = $v; 
 +    } 
 +    return $array; 
 +} 
 +</code> 
 + 
 +For array and object keys this would give an ''Illegal offset type'' warning. For ''NULL'' the ''%%""%%'' key is used, doubles are truncated to the integral part, resources use their resource ID and issue a warning, booleans are cast to integers. 
 + 
 +In order to support this a new function is added in ''Zend/zend_API.h'' (which more or less reimplements the internal inline function ''zend_fetch_dimension_address_inner''): 
 + 
 +<code c> 
 +/* The refcount of value is incremented by the function itself */ 
 +ZEND_API int array_set_zval_key(HashTable *ht, zval *key, zval *value); 
 +</code>
  
 ===== Patch ===== ===== Patch =====
  
-A preliminary patch implementing the above proposal can be found here: https://github.com/php/php-src/pull/278+The patch for this change can be found here: https://github.com/php/php-src/commit/fcc6611de9054327441786e52444b5f8eecdd525
  
 The change itself is rather small, but there are quite a few extensions that require minor adjustments to use the new API. The change itself is rather small, but there are quite a few extensions that require minor adjustments to use the new API.
  
-===== Open questions =====+===== Vote ===== 
 + 
 +Voting ends on March 6th. A 50% + 1 majority is required. This RFC targets PHP 5.5.
  
-The main open question are iterator/array interactions, e.g. when an iterator is converted to an array with ''iterator_to_array''. What should be done with the keys that are valid in the iterator, but not in the array? I think the best approach would be to just set the array keys with the exact same semantics as PHP would do (i.e. with all casts and warnings). I couldn't yet find a function in the API that does this though. Maybe have to expose the inline functions from ''zend_execute.c'' for that :)+<doodle title="Remove type-restrictions on foreach keys?" auth="nikic" voteType="single" closed="true"> 
 +   * Yes 
 +   * No 
 +</doodle>
rfc/foreach-non-scalar-keys.1361278021.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools