You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A vec array is a container whose keys are zero-based continuous integers. This mirrors the behavior of the Vector class. This will be an array at runtime with extra restrictions to allow it to be used safely like a Vector from the type checkers perspective. This focuses mainly on the desired runtime behavior, but if there are questions for how it will interact with the type checker I'll be happy to discuss.
Literal Constructor
A vec is constructed using the literal expression vec[].
$vec=vec[]; // Empty vec-array$vec=vec['a', 'b', 'c']; // vec-array of 3 elements
This is a static expression, so it can be used in a static initializer.
classC {
publicstatic$vec=vec['a', 'b', 'c'];
}
Traversable Constructor
A vec can also be constructed from any Traversable type, using the traversable constructor.
$array=array('a', 'b', 'c');
$vec=vec($array); // constructs vec-array from another array
Adding Elements
To preserve the property of having continuous integer keys new elements can only be added to a vec using the array append operator.
$vec=vec[];
$vec[] =1; // Allowed$vec[0] =2; // Allowed$vec[10] =3; // Error: 10 is out of bounds for the vec-array
Removing Elements
Using unset on a vec type will demote it to the dict type. If you want to preserve the vec property then you will need to use the various array functions that operate at the beginning or end of an array such as array_pop, array_push, array_shift, array_unshift, etc.
$vec=vec[1, 2, 3, 4];
array_pop($vec); // Now vec[1, 2, 3]array_shift($vec); // Now vec[2, 3]unset($vec[1]); // unsetting changes a vec to a dict[ 0 => 2]
In both this and #6452, how do you propose to handle typing the typing of a vec or dict that's initialized to be empty?
Would this be allowed:
$vec = vec[];
$vec[] = 1;
$vec[] = '1'; // Would we error here?
And what happens when multiple code paths use it differently (ignore the fact that there is nothing at index 0 yet, I just needed something to illustrate the point of the branch):
$vec = vec[];
$vec[] = is_int($vec[0]) ? 1 : '1';
I think it would be reasonable to allow a syntax for initializing an empty vec or dict that allows keys/values only of a certain type.
@Orvid - This isn't a new issue in this proposal. The same thing can occur with Collections today.
$vec=Vector {};
$vec[] =1;
$vec[] ='1';
The type is considered "unresolved" of Vector<int | string>. The vec type would work the same. Here is a talk which goes into more detail on how the type checker works if you are interested. https://www.youtube.com/watch?v=aN22-V-b8RM
Would this be used in place of the current single type-argument array? (e.g., array<string>) Likewise, would dict replace the dual type-argument array? (e.g., array<int, string>)
If so, would both type be equivalent, would the current array types be deprecated, or would they stay the same?
If they become equivalent, would using the current array syntax also be valid when the type of the array is known? Eg:
Yes!
1 lis 2015 01:40 Orvid King [email protected] napisał(a):If it's being brought into the language, then wouldn't this be the right time to solve that limitation?
—Reply to this email directly or view it on GitHub.
Activity
Orvid commentedon Oct 31, 2015
In both this and #6452, how do you propose to handle typing the typing of a
vecordictthat's initialized to be empty?Would this be allowed:
And what happens when multiple code paths use it differently (ignore the fact that there is nothing at index 0 yet, I just needed something to illustrate the point of the branch):
I think it would be reasonable to allow a syntax for initializing an empty
vecordictthat allows keys/values only of a certain type.dlreeves commentedon Oct 31, 2015
@Orvid - This isn't a new issue in this proposal. The same thing can occur with Collections today.
The type is considered "unresolved" of
Vector<int | string>. Thevectype would work the same. Here is a talk which goes into more detail on how the type checker works if you are interested. https://www.youtube.com/watch?v=aN22-V-b8RMsimonwelsh commentedon Oct 31, 2015
Would this be used in place of the current single type-argument array? (e.g.,
array<string>) Likewise, woulddictreplace the dual type-argument array? (e.g.,array<int, string>)If so, would both type be equivalent, would the current
arraytypes be deprecated, or would they stay the same?If they become equivalent, would using the current array syntax also be valid when the type of the array is known? Eg:
If the
arraytypes remain, will the new types (vec,dictandkeyset) type asarraytoo?Orvid commentedon Nov 1, 2015
If it's being brought into the language, then wouldn't this be the right time to solve that limitation?
ozzus666 commentedon Nov 1, 2015
Yes!
1 lis 2015 01:40 Orvid King [email protected] napisał(a):If it's being brought into the language, then wouldn't this be the right time to solve that limitation?
—Reply to this email directly or view it on GitHub.
simonwelsh commentedon Nov 1, 2015
@Orvid that problem exists for anything using generics, it isn't specific to this, so isn't being brought into the language.
The actual type isn't known until it is passed through somewhere that makes it concrete (usually, an argument or return type).
Add new array-data operations for Hack arrays
Some misc pre-vec cleanup
Make PackedArray helpers more generic
Add basic support for Hack vec array
Add VecArrayInit
Add ToVec array-data function
Add serializer/unserializer support for Hack vec arrays
Add HHBC and HHIR support for Hack vec arrays
Add parser support for Hack vec arrays
Add test cases for Hack vec arrays