Roadmap

[morrisonlevi]

Initially the RFC did not include modifying core interfaces, and I argued for that feature and to provide at least a small data structures library built on top of the core interfaces to prove the feature. I think I am backtracking now. I still think that has value; it's just that this feature is so large I think we need to break it into 3 or more stages.

Stage 1

Includes:

• Generic classes and interfaces with upper-bounds and declaration-time variance.
• Serialization support.
• A mixed type, with whatever name the bikeshedding produces.
• Makes ArrayAccess interface generic (others untouched).
• A small data structures library that uses generic features, but loses type information for things like Iterator.
  • Possible candidates:
    • Vector<Element>, Stack<Element>.
    • Dictionary<Key, Value> - doing the hash/eq bit might be difficult given that recent RFC didn't pass.
• Default type parameters.

Does not include:

• Generic traits.
• Generic functions, closures, and methods.
• Generic arrays.
• Where clauses.
• Modifying core interfaces such as Traversable, Iterator, and IteratorAggregate.
• Associated types.

If we don't have a generic ArrayAccess interface then a lot of the data structures would be inconvenient to use. I'm about 99% confident that this defintion should work without BC issues, and would be fully correct:

interface ArrayAccess<in K = mixed, V = mixed> {
  function offsetExists(K $offset); // returns convertable to bool

  // Yes, nullable return type.
  // Inheritors can narrow that to only V and throw if they want.
  function offsetGet(K $offset): ?V;

  function offsetSet(?K $offset, V $value); // return is ignored
  function offsetUnset(K $offset); // return is ignored?
}

Stage 2

Prerequisites:

• Covariant return types.
• Preferably some more restrictions on built-in interfaces, such as IteratorAggegrate::getIterator() being required to return a traversable.

Includes:

• Generic traits.
• Generic functions, closures, and methods.
• Where clauses.
• Default type parameters.
• Modifying core interfaces such as Traversable, Iterator, and IteratorAggregate.
• Associated types.
• Improving data structures from phase1 to use new features; possibly adding more structures.

Does not include:

• Generic arrays.
• Modifying built-in functions to be be generic.

Stage 3

Includes:

• Generic arrays.
• Modifying (some) built-in functions to be be generic.

---

What do you think?

[orolyn]

It sounds good, I favour a staged approach and stage one has all of the features I initially envisioned. I assume stage 2 is aimed at PHP8 based on last discussion?

[linaori]

Please don't wait till php8. I don't want to have to wait a few years until this becomes available. I'm also not a fan of adding new features in major versions, best to only remove deprecations so you can update without too many problems (see symfony release cycle).

[morrisonlevi]

To be effective Stage 2 does require a BC break, so yes, Stage 2 would target 8.0. If we don't get a 7.4 before 8.0 then we'll need to think carefully and try to get all the BC stuff done then, even though we won't be building on it yet.

[Deltachaos]

Would be nice. The question is: How realistic is it that the PHP team will adopt this?

[morrisonlevi]

Adopt generics? I think it's reasonably likely to pass, although honestly maybe not the first time around. Large RFCs tend to fail their first time, then pass later.

Right now we're not that close to proposing it anyway.

[anthonyvancauwenberghe]

Why would you put generic arrays in stage 3? Seems like something that's easier to implement than generic traits/functions?

Can you start finishing up the draft for stage 1 changes? Would love to see this stuff in php 7.4