Psalm: Add sequential-array and non-empty-sequential-array types

[muglug]

This is necessary for Psalm to detect that this is always ok:

function foo(string $s) {
  echo explode(",", $s)[0];
}

but this is not always:

function bar(string $s) {
  echo explode(",", $s)[1];
}

a sequential-array is the PHP equivalent of Hack's vec type and Java/C# arrays, though it can quickly lose its sequentialness e.g. by adding an arbitrary offset $a[$foo] = "bar".

In use:

/**
 * @return non-empty-sequential-array<string>
 */
function comma_separate(string $s) : array {
  return explode(",", $s);
}

/**
 * @return sequential-array<string>
 */
function comma_separate_without_last(string $s) : array {
  return explode(",", $s, -1);
}

[muglug]

Maybe vector-arrray is a better name

[muglug]

cc @weirdan @TysonAndre @Ocramius who may have thoughts on names

[iluuu1994]

I like sequential-array as it's very fitting. The difference between an array and vector is not clearly defined but usually vector denotes that the data type is growable (C++ or Rust, for example).

[muglug]

Another alternative is packed-array but that may be too specific to an implementation detail

[muglug]

Or list-array, but that may not be descriptive enough

[iluuu1994]

This is probably unfeasible but I'd love it if sequential-array were the default. Foo[] or array<Foo> should always (IMO) mean sequential-array<Foo> unless you specify the key-type (array<int, Foo> or array<string, Foo>).

Again, probably unfeasible as most code doesn't make that distinction.

[Ocramius]

In internals, it's generally called "packed array", but array-list is indeed correct. (dash kinda needed for now)

[Ocramius]

Foo[] or array<Foo> should always (IMO) mean sequential-array<Foo>

That ship has sailed looooong time ago: Foo[] means "a bunch of Foo instances, for which we don't care about key access"

[muglug]

That ship has sailed looooong time ago

Yeah, sadly. I wish PhpDoc had made that distinction, but it didn’t.

[TysonAndre]

"packed arrays" can have holes as they're defined in internals, and don't mean much outside of php internals.

"sequential arrays" has the ambiguity of where the sequence starts

Just list<Foo> might work and be concise (in the general definition of list, not php's keyword definition), because list is reserved for list($x) = syntax.

I'd also considered ...Foo, but didn't like it: that makes it ......Foo for a sequential array of sequential array of Foo, @param ...$this $var for an array of 0 more $this values, etc. (Forcing brackets might make that tolerable). I also didn't like array<consecutive-int, Foo> or array<..., Foo> since the key "type" wouldn't make sense elsewhere

[Ocramius]

The wording list can collide with userland though, hence a - would be preferable

[TysonAndre]

Being able to represent this would also be useful for checking accepts_varargs(...$args) and $v = [...$args];

The wording list can collide with userland though, hence a - would be preferable

Could you give examples of userland code you had in mind? It's a reserved keyword, making it unlikely to be used in most userland code

php > class list {}
Parse error: syntax error, unexpected 'list' (T_LIST), expecting identifier (T_STRING) in php shell code on line 1
php > use ArrayObject as list;
Parse error: syntax error, unexpected 'list' (T_LIST), expecting identifier (T_STRING) in php shell code on line 1

---

EDIT: It'd be a notice about keys possibly being unexpectedly ordered

php > var_export([...[32 => 'description']]);
array (
  0 => 'description',
)

[muglug]

Could you give examples of userland code you had in mind? It's a reserved keyword, making it unlikely to be used in most userland code

Oh that changes my opinion

[Ocramius]

Oh, totally forgot about the keyword collision, thanks!

[weirdan]

list is fine, one other option could be dense-array (as opposed to sparse arrays).

[muglug]

started working on this under the name list/non-empty-list: https://github.com/vimeo/psalm/compare/list-types