Reified generics

[php-generics]

Add reified generics to PHP

Summary

This PR adds reified generics to the Zend Engine — generic type parameters that are preserved at runtime and enforced through the type system. Unlike type erasure (Java/TypeScript), generic type arguments are bound per-instance and checked at every type boundary.

Syntax

Generic classes

class Box<T> {
    public T $value;
    public function __construct(T $value) { $this->value = $value; }
    public function get(): T { return $this->value; }
}

$box = new Box<int>(42);       // explicit type arg
$box = new Box(42);            // inferred from constructor — T = int
$box->value = "hello";         // TypeError: cannot assign string to property Box<int>::$value of type int

Multiple type params, constraints, defaults

class Map<K: int|string, V = mixed> {
    // K is constrained to int|string, V defaults to mixed
}

class NumberBox<T: int|float> {
    public function sum(T $a, T $b): T { return $a + $b; }
}

Variance annotations

class ReadOnlyList<out T> { /* covariant — can return T, not accept T */ }
class Consumer<in T>      { /* contravariant — can accept T, not return T */ }

Wildcard types

function printAll(Collection<? extends Printable> $items): void { ... }
function addDogs(Collection<? super Dog> $kennel): void { ... }
function count(Collection<?> $any): int { ... }

Generic traits

trait Cacheable<T> {
    private ?T $cached = null;
    public function cache(T $value): void { $this->cached = $value; }
}

class UserCache {
    use Cacheable<User>;
}

Generic functions and closures

function identity<T>(T $x): T { return $x; }

$map = function<T>(array $items, Closure $fn): array<T> { ... };

Nested generics

$nested = new Box<Box<int>>(new Box<int>(42));  // >> handled by lexer splitting

Static method calls with generics

$result = Factory<int>::create();

instanceof with generics

if ($obj instanceof Collection<int>) { ... }

Inheritance

class IntBox extends Box<int> {}           // bound generic args
class PairBox<A, B> extends Box<A> {}      // forwarded params

// Method signatures verified against parent's resolved types

Runtime enforcement

All type boundaries are checked at runtime:

• Constructor args — new Box<int>("x") throws TypeError
• Method params — $box->set("x") throws TypeError when T = int
• Return types — return "x" from a method declared (): T with T = int throws TypeError
• Property writes — $box->value = "x" throws TypeError
• Error messages include resolved types: Cannot assign string to property Box<int>::$value of type int

Ecosystem integration

• Reflection — ReflectionClass::isGeneric(), ::getGenericParameters(), ReflectionObject::getGenericArguments(), ReflectionGenericParameter (name, constraint, default, variance)
• Serialization — serialize(new Box<int>(42)) produces O:8:"Box<int>":1:{...}, unserialize() restores generic args
• Debug display — var_dump shows object(Box<int>)#1, stack traces show Box<int>->method()
• Opcache — SHM persistence and file cache serialization
• JIT — inline monomorphization with pre-computed bitmask fast path

Edge cases covered

• Anonymous classes (new class extends Box<int> {})
• Clone preserves generic args
• Autoloading (Collection<int> triggers autoload for Collection)
• class_alias inherits generic params
• WeakReference/WeakMap with generic objects
• Fibers across suspend/resume
• Type argument forwarding (new Box<T>() inside generic methods/factories resolves T from context)
• Compile-time rejection of void/never as type args

Performance

Benchmarked at 1M, 10M, and 100M iterations on arm64, both master (PHP 8.5.3 NTS) and generics branch (PHP 8.5.4-dev NTS) built as release binaries.

Generic args use refcounted sharing — new Box<int>() adds a refcount instead of deep-copying, eliminating 4 allocator round-trips per object lifecycle. Pre-computed scalar bitmasks are stored inline (no separate allocation).

Generic vs non-generic overhead (same binary)

Results stabilize at higher iteration counts as warmup and noise are amortized.

Operation	1M interp / JIT	10M interp / JIT	100M interp / JIT
Object creation	-8% / -10%	-7% / -11%	-7% / -11%
Method calls (set+get)	-16% / -9%	-14% / -10%	-14% / -10%
Property assignment	-3% / +1%	-3% / +1%	-2% / +0%
Memory per object	+0 bytes	+0 bytes	+0 bytes

Absolute throughput (generics branch, JIT, ops/sec)

Operation	1M	10M	100M
new GenericBox<int>(42)	37.3M	37.1M	37.4M
GenericBox<int>->set+get	60.3M	57.7M	60.2M
GenericBox<int>->value = N	94.9M	93.1M	94.2M
new GenericBox<GenericBox<int>>	22.0M	22.0M	21.9M

Non-generic regression check

Non-generic classes (PlainBox, UntypedBox) were benchmarked on both master and the generics branch under identical conditions (release NTS, same image). Results at 100M iterations (most stable) confirm zero performance regression on existing code paths:

Operation	Class	master (JIT)	generics (JIT)	delta
Object creation	PlainBox	41.3M ops/s	42.0M ops/s	+2%
Object creation	UntypedBox	49.3M ops/s	45.6M ops/s	-8%
Method calls	PlainBox	66.6M ops/s	66.6M ops/s	+0%
Method calls	UntypedBox	77.0M ops/s	77.4M ops/s	+0%
Property assign	PlainBox	96.1M ops/s	94.1M ops/s	-2%
Property assign	UntypedBox	116.0M ops/s	113.0M ops/s	-3%
Memory	PlainBox	94 bytes	102 bytes	+8 bytes
Memory	UntypedBox	82 bytes	90 bytes	+8 bytes

The +8 bytes per object is the generic_args pointer field added to zend_object (NULL for non-generic objects). Throughput deltas are within cross-build variance (+-5%); no systematic code path slowdown was observed.

Memory overhead

Object type	bytes/obj
PlainBox (typed int)	102
GenericBox<int> (explicit)	102
GenericBox (inferred)	122
GenericBox<GenericBox<int>>	90

Generic objects with explicit type args have zero memory overhead vs non-generic typed objects — refcounted args are shared with the compiled literal. Inferred args (+20 bytes) allocate a new args struct. Nested generics benefit most from sharing (90 bytes vs 210 bytes before optimization).

[DanielEScherzer]

Please have this target the master branch of PHP, patch-specific branches like 8.5.4 are for release management, and older version branches like 8.5 are for bugfixes or security fixes, new feature are added to the master branch

[iluuu1994]

Hi @php-generics 👋 May I ask two things:

1. How much was AI involved in the creation of this PR?
2. Is there a reason you're not disclosing your identity?

[rennokki]

Serialization — serialize(new Box(42)) produces O:8:"Box":1:{...}, unserialize() restores generic args

Won't this break existing serialized strings in case of an upgrade? I think of having existing serialized strings in a database and upgrading it would break it.

Also, usually isn't there an RFC for these kind of things?

[ramsey]

This requires an RFC and discussion on the internals mailing list.

My initial impression is this was coded 100% by an AI agent, and perhaps the @php-generics account itself was created by an AI agent. All code in this PR should be highly scrutinized to ensure it's not introducing vulnerabilities.

[bwoebi]

The only tests for generic functions which I see are simple identity functions. Can we also have tests which show proper behaviour for generics in return types (e.g. function x<T>(T $a): T { return 1; } x("a"); should probably fail. I see some EG(static_generic_args), but not seeing how it would be preserved for return types (with nested calls at least, that is).

[cvsouth]

How much was AI involved in the creation of this PR?

If it's any indication the first line of the summary contains an em-dash, there are 12 of them in the relatively short description and they are used throughout the code comments. I'd guess at 100% of it.

[jorgsowa]

If it's any indication the first line of the summary contains an em-dash, there are 12 of them in the relatively short description

Not only dashes. Whole structure of PR description, benchmark results, comments in Code, tests structure. A lot of indicators of AI.

I'm not against AI, but it's sad that author didn't even invest time to learn how such changes should be performed in PHP - through RFC. It's just one more prompt to learn it.

[rennokki]

This requires an RFC and discussion on the internals mailing list.

My initial impression is this was coded 100% by an AI agent, and perhaps the @php-generics account itself was created by an AI agent. All code in this PR should be highly scrutinized to ensure it's not introducing vulnerabilities.

It is 100% AI, and I would not trust this unless there is a human that rewrites it while diligently considers any bugs.

I'm not against AI, but it's sad that author didn't even invest time to learn how such changes should be performed in PHP - through RFC. It's just one more prompt to learn it.

• Yes, the PR sounds very specific and lacks any "I" in the text, lacks human touch.
• The lack of RFC also screams to me that making a bot to publish an RFC is definitely hard to make it sneaky, you'd be spotting it from a mile
• The account is literally 1 day old and it has only one follower (not sure if it's the author)

[php-generics]

still drafting PR.

@php-generics Can you try to maintain a clear commit history for ease of review, i.e. keep commits scoped to a single logical change (e.g. fixing a single bug) with a clear commit message.

The initial commit should ideally also be split into several commits that build onto each other. e.g. first introducing the syntax changes in the parser that simply emit an error during compilation, then adding support for creating generic functions, then generic classes, then type checking support for passing a generic class to a function and then Reflection support.

You have no other choice but to trust me at this point.

And as Ramsey correctly remarked, this will a proper RFC defining the desired semantics to be considered for inclusion in PHP.

Thank you for the feedback. You're right about the commit history - I'll restructure it into logical, reviewable commits that build on each other.

Regarding the RFC - fully understood. This is a working draft / proof of concept to explore the design space and demonstrate feasibility, not a merge-ready proposal. I'm still actively working on it and will do my best to incorporate all the feedback from this discussion.

[bwoebi]

Why not progressive inference?

The approach described in the question (min-type/max-type widening from method calls) is interesting but fundamentally at odds with reified generics:

Aliasing breaks it. If two variables reference the same object, a call on one would silently change the type seen by the other:

$a = new Collection();
$b = $a; // same object
$a->add(1); // would narrow to
$b->add("text"); // would widen to <int|string>, affecting $a too

Well yes, there's just one object, whatever variables you assign that object to. That line of reasoning is possibly valid for arrays, but not objects.

Non-local reasoning. You can't know an object's type without tracing every method call on it. That defeats the purpose of type safety — the whole point is to declare your intent and have the engine catch mistakes.

The type safety model of PHP is fundamentally opt-in - the maximally wide type is the default. If I use a class, which happens to use mixed right now (because the type is not flexible enough), and migrates to generics, it is necessarily a break. If you don't have to specify generics manually, code which was supposed to work previously should just continue to work.

Not specifying a type simply means "I don't need this explicitly typechecked here".

Types are also much less valuable in local contexts than in global contexts.

E.g. the collection, I just want to create it here - and then maybe pass to a library, which has constraints on the collection. I don't care about my specific generic type of collection - I care about the fact that the callee accepts my collection.
Modern strongly typed languages like Rust generally use type-inference to avoid requiring generics being specified in local contexts as much as possible (we definitely should not require more explicit generic specifying than Rust does - after all the advantages of dynamic languages is being ... somewhat dynamic). They do, however, require the type to be precise on all function boundaries though.

PHP does not necessarily have to require precise types on function boundaries. I, for instance, hate it that every small helper function, in a very local context, requires naming of the full type including generics in Rust.

You certainly can opt-in to having generics explicitly specified, when you actively need more complex type checking. You probably should be explicit in generics when injecting objects into the wider scope of your application or library. But that's a choice the programmer has to make.

The goal of PHP is to have types as non-invasive as possible. Forcing the type on the constructor goes counter that. (minus the constructor-arg inference).

Runtime cost. Every method call would need to re-validate all existing data in the collection against the new wider type, or the type system would be unsound.

It doesn't. It only has to check against the min- and max-types. The min-types should only ever be widened and the max-types only ever be narrowed. Regardless of the current values assigned to properties using the specific generic parameters.
This should be fairly simple.

You could think about explicit mechanisms to cast between types, but that's out of scope of my question here (which then also incur that checking cost).

It's what static analyzers already do. PHPStan and Psalm already perform flow-sensitive type narrowing at analysis time — that's the right layer for this kind of inference. A runtime type system should be simpler and more predictable.

Not quite. Static analysis can only shrink types, never widen them. However, unless you want every generic object a Collection<mixed> by default (which you obviously also cannot forward to any other function expecting Collection<int|string> for example), you're going to have to specify Collection<string|int> manually.

EDIT: More specifically: As long as the type is fully in the static analyzers domain, it can both shrink and widen it. But it cannot widen any explicitly specified type.

PHPStan can then go and infer the fact for you that there are only ever strings contained in that collection and tell you that the type is possibly too wide. Or just pass a local Collection<string> to a function accepting Collection<int|string> if it infers through escape analysis that no local type invariants are violated.

But yeah, in fact, having progressive typing gives more freedom to static analysis.

P.s.: For actual discussion, please avoid AI-generated answers (sure "format this table for me" is fine - but don't do that for the actual content of the discussion :-D)

[php-generics]

@bwoebi

Actually thinking about it more - both models can coexist pretty naturally. The rule would be simple: if you specified the type (explicitly or via constructor inference), it's frozen. If you didn't, progressive mode kicks in.

// frozen - explicit type
$c = new Collection<int>();
$c->add(1);       // ok
$c->add("text");  // TypeError

// frozen - inferred from constructor arg
$box = new Box(42);    // T = int
$box->set("hello");    // TypeError

// progressive - no type given, no constructor inference possible
$c = new Collection();
// min = never, max = mixed
$c->add(1);            // min widens to int
$c->add("text");       // min widens to int|string
foo($c);               // foo(Collection<int|string|bool>) narrows max
$c->add([]);           // TypeError - array outside max-type

Implementation-wise this fits into the current architecture. Right now when obj->generic_args == NULL everything passes (unconstrained). Instead of that, NULL would mean "progressive mode" - and instead of just returning true in the type check, we'd update the min-type.

Would need a separate structure for the progressive state:

Situation	generic_args	progressive_args	Mode
new Box<int>()	set	NULL	frozen
new Box(42)	set (inferred)	NULL	frozen
new Collection()	NULL	allocated lazily	progressive

Type checking logic becomes: if generic_args is set, check against it (frozen, same as now). If progressive_args exists, check against max-type and widen min-type. If neither, first operation on a generic param, allocate progressive_args and set initial min-type.

One open question - should a progressive type ever "freeze"? Like once max-type narrows to equal min-type, does it become effectively frozen from that point? Or does it stay progressive forever? That probably needs more thought and would be good to discuss in an RFC.

But the core idea of "both models, determined by whether you specified the type" feels clean and backwards compatible with what's already there.

Let me know if I'm understanding your proposal correctly or if I'm missing something.

[bwoebi]

Explicit types certainly freeze it.

Whether constructor inference also should freeze it or just set a min-type, I'm not sure about. After all a constructor is also just a method call. Maybe new Box<>(12); auto-triggers freezing (<> as in "please infer here") and new Box(12) doesn't?
This should be subject to some debating in the RFC too.

One open question - should a progressive type ever "freeze"? Like once max-type narrows to equal min-type, does it become effectively frozen from that point? Or does it stay progressive forever? That probably needs more thought and would be good to discuss in an RFC.

Yes, once min=max it's effectively frozen.

As I said before:

You could think about explicit mechanisms to cast between types, but that's out of scope of my question here (which then also incur that checking cost).

And yep, everything else is spot-on.

[derickr]

I've locked this PR for now, as it is very clear that any comments that are being given by the developers are being fed directly into a chat bot. That is extremely rude.

If you're interested in progressing this, then go through our normal RFC procedure. This method of contributions is not productive.

[bukka]

@php-generics Did you make sure that you fed it with the article that Arnaud produced: https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collections/ . As it was noted, there was also experiment PR (which is what was evaluated in that article) : arnaud-lb#4 so you could build on that.

What I'm asking is whether this can have any answer on the mentioned issues? If there's no solution for it, then I think there's really not much point in dicussing other details...

[iluuu1994]

It would also be great if you could fix the compile warning:

Zend/zend_compile.c:9908:22: error: variable ‘key’ set but not used [-Werror=unused-but-set-variable]
 9908 |         zend_string *key;

Which breaks make with -Werror in CI. I don't want to run this locally yet (who knows what's in here), but then we'd at least get an estimate on the performance impact through the benchmarking CI job.

[bwoebi]

@php-generics

Also fixes subtype compatibility so Box is accepted where
Box<int|string> is expected (subset check instead of exact equality).

That's not correct - generic type parameters must not be covariant by default. That's what in and out are for. Only a Box class defined as Box<out T> can allow Box<int> to be passed to Box<int|string>, but not Box<T>.

On the callee side (unless the type itself is out) Box<? super int|string> is the proper type for such situations. (I think I'd personally prefer Box<out int|string> (and Box<in int|string>) rather than the Java-inspired syntax, as in "I can get an int|string out of this Box", or "I can put an int|string into this Box".)

[azjezz]

The syntax used here is not possible in PHP.

The following is completely valid PHP code today, and this PR ( assuming it works ) makes it an error.

<?php

const A = 1;
const B = 2;
const C = 3;

$a = [A<B, B>(C)];

ref: https://3v4l.org/S2PTJ

If the author did not bother to verify that the syntax is even possible, I don't trust the logic to be sound.

[bwoebi]

@azjezz To be fair, Arnaulds PR did also not solve this properly, requiring > > instead of >> for nested generics. Technically it's unambiguous, it's just parser and lexer limitations. And we do definitely want this syntax.

[A<B, B>(C)] is by itself not ambiguous (but broken in this PR!) - a new is missing here. But yes, [new A<B, B>(C)] is ambiguous. (and should be shifted towards generics resolution, effectively theoretically breaking code, but new A < B is nonsense.)

[iluuu1994]

Also, the >> ambiguity is solved in this PR (through lookahead in the lexer). Invalidating some obscure syntax is not necessarily a blocker for new syntax anyway.

If the author did not bother to verify that the syntax is even possible, I don't trust the logic to be sound.

For obvious reasons, this PR is not getting merged anytime soon. It needs an RFC and the code would effectively have to be completely rewritten to verify its correctness.

However, if the PR can demonstrate a workable solution for generics exists, that's useful in it's own right, even if none of the code is actually used. When we see the PR doesn't go anywhere or that there are fundamental, unsolvable issues, this PR can always be closed.

[azjezz]

@bwoebi [A<B, B>(C)] is ambiguous, it could be a function call, using two type parameters, and 1 argument.

The solution to this exists, which is to use Turbo-fish ( rust style ::< ).

https://doc.rust-lang.org/reference/glossary.html?highlight=turbo#turbofish

[bwoebi]

@azjezz This PR doesn't allow generically parametrized function calls (function_call terminal in parser has no such thing). I'm not sure whether we need this in PHP or not.

[azjezz]

We do need this, espically if we are talking about reified generics, here is a use case:

function is_instance_of<T: object>(object $value): bool { return $value instanceof T; }

if (is_instance_of::<Foo>($value)) {

}

This already works in Hack: https://docs.hhvm.com/hack/reified-generics/reified-generics/ / https://docs.hhvm.com/hack/reified-generics/reified-generics/#type-testing-and-assertion-with-is-and-as-expressions ( Hack broke this syntax when it was first released, so BC was no a concern )

[bwoebi]

Yeah, you're right, it's useful for freestanding generics (and return type assertions, when T is return type only).

[azjezz]

Another reason is some libraries offer a way to construct objects using functions ( or static methods, which is just as ambiguous as function calls )

final class Collection<K, V> {
    public static function create<A, B>(): static<A, B> {
      return new static::<K, V>();
    }
}

function create_collection<K, V>(): Collection<K, V> {
  return Collection::create::<K, V>(); // <- this is ambiguous without turbofish
}

$collection = create_collection::<string, string>();

[arnaud-lb]

As far as I understand, the PR uses runtime information for inference during constructor or method calls.

This will make typing unstable / unpredictable, leading to type errors at runtime (which a type system is meant to avoid). Additionally, it impairs static analyzers and humans reading the code, as they are unable to predict actual types.

Consider the following example:

class A {}
class B extends A {}

function test(A $value) { 
    // Is this a Box<A>, Box<B>, or something else?
    // We don't know, as $value is allowed to by any subtype of A, as per API
    $box = new Box($value);

    // This breaks in unpredictable ways:
    doSomething($box);
}

function doSomething(Box<A> $box) {}

test(new B());

The type of $box can not be predicted, as it depends on the runtime type of $value, which we don't know. Therefore this code is prone to break.

Of course we can write new Box<A>($value) here, but I suspect this will need to be done most of the time.

To avoid these pitfalls, type inference needs to use static information only. In the above example, $box would always be a Box<A>. This is trivially achieved in static analyzers, but not in the engine. I've explored a solution to this in arnaud-lb#4 (comment).

---

Regarding compound types: Checking that Box<A|B|C> satisfies an argument type of Box<...> is O(n²) or worse. This will affect the performance of argument passing, returning from functions, and assignment to properties.

This doesn't matter as much in static analyzers, but doing this in the engine will be slow. It has been suggested that if we were to get generics in core, it shouldn't support unions/intersections.

[bwoebi]

@arnaud-lb Not quite, it just means that you must not infer that constructor args immediately. If you were to progressively use min- and max-types like in #21317 (comment) for everything (i.e. including constructors), that would work out.

I would really hate generics without unions and intersections. You really have these often, just like int|float and many others. You just tend to not have 100 different types in an union.
Also: when you progressively type, you tend to get Box<somesupertype> as the actual max-type with the first function call typechecking against the object (O(n) once). Which you'll then be able to compare in O(1).
Also you could do caching of complex type comparisons for the whole runtime of the process if this still poses a problem (i.e. when creating a Box<A|B|C> you store at the same time a lookup-integer (runtime cacheable) that it's compatible with Box<Super_of_A_B_and_C>). Or encode complex types in an ordered normalized form, so that invariant check comparisons are really a memcmp (= inexpensive).

This is not necessarily insurmountable.

[arnaud-lb]

Not quite, it just means that you must not infer that constructor args immediately. If you were to progressively use min- and max-types like in #21317 (comment) for everything, that would work out.

The example above breaks with progressive inference too:

class A {}
class B extends A {}

function test(A $value) { 
    $box = new Box();
    $box->setValue($value); // Box<min=B>, in this case

    // Breaks because $box is Box<min=B>, but doSomething() accepts only a Box<A>
    doSomething($box);
}

function doSomething(Box<A> $box) {}

test(new B());

To make this work, I believe that we would need bidirectional type inference to determine that max = A in $box = new Box() due to doSomething($box).

I would really hate generics without unions and intersections. You really have these often, just like int|float and many others. You just tend to not have 100 different types in an union.

I agree

Also: when you progressively type, you tend to get Box as the actual max-type with the first function call typechecking against the object (O(n) once). Which you'll be able to compare in O(1).
Also you could do caching of complex type comparisons for the whole runtime of the process if this still poses a problem (i.e. when creating a Box<A|B|C> you store at the same time a lookup-integer (runtime cacheable) that it's compatible with Box<Super_of_A_B_and_C>). Or encode complex types in an ordered normalized form, so that invariant check comparisons are really a memcmp (= inexpensive).

We can not eliminate all overhead. Calling generic objects will have overhead to update min (subtype checks, potentially creating new union types), passing generic objects to typed args / return values / props as well. Maintaining a lookup table or an order lattice also has a cost, which likely needs to be paid every request.

[bwoebi]

// Breaks because $box is `Box<min=B>`, but doSomething() accepts only a `Box<A>`

No, it's Box<min=B, max=mixed> at that point. Which A fits into. Thus passing to doSomething accepting Box<A> then causes to it become Box<A>, given that the generic A parameter is invariant here.

We can not eliminate all overhead

Absolutely. That's also really the point where we would need to start investing into more type-check elision via Optimizer. But it's sort-of a tangential problem.

[Danack]

Hi @php-generics,

Please could you pass this message on to your controlling human, assuming you have one.

I'm Danack. I'm not a PHP core contributor, but I am someone who has helped guide others through the RFC process.

I have written a couple of articles on Understanding RFC attitudes and RFC etiquette

Assuming you're not an existing RFC author who is playing a 'funny' prank, I'd like to offer my help in guiding you through 'The Mysterious PHP RFC Process'.

My email is on my github page, or Twitter (MrDanack) or I am ping'able in Room11 on StackOverflow.

Which seeing as it's currently barely active, might be a place for very well behaved bots to ask questions.

iluuu1994 wrote:

2. Is there a reason you're not disclosing your identity?

At some point, a lack of identity will become an impediment to this proposal progressing.

A core foundation of Open Source is the web of trust* between contributors.

That foundation is removed by anonymous contributors.

cheers
Dan
Ack

• actual amounts may vary. Negative values of trust are possible.

[arnaud-lb]

@bwoebi

// Breaks because $box is `Box<min=B>`, but doSomething() accepts only a `Box<A>`

No, it's Box<min=B, max=mixed> at that point. Which A fits into. Thus passing to doSomething accepting Box<A> then causes to it become Box<A>, given that the generic A parameter is invariant here.

Indeed, my bad.

Is there prior work on this idea?

Here are some problematic cases I could think of:

The following example breaks local reasoning: we don't know if the code is correct because bar() may update types to anything. We can fix that by freezing generic objects when passing them to parameter-less types (such as mixed, object, Collection), but this is inconvenient as this will likely not result in the desired types: In this example, $c would be a Collection<mixed> after the call to bar(). Also, inverting the order of foo() and bar() would assign a different type to $c.

function foo(Collection<A> $coll) {}
function bar(mixed $obj) {}

$c = new Collection();
bar($c); // what is the type of $c after that?
foo($c); // does it breaks?

In the following example, what should references to T resolve to? We can not use type ranges to evaluate instanceof, as this would lead to either false positives or negatives. Freezing types before evaluating the expression would break local reasoning like in the previous example.

class C<T> {
    function f($p) {
        // what is T?
        if ($p instanceof T) {
            // ...
        }
        new T();
        T::method();
    }
}

$c = new C();
$c->f(new Foo());

Similarly, in the following example we can not evaluate the instanceof expression unless we freeze types, which would be unexpected.

$c = new C();
if ($c instanceof C<Foo>) {
    // ...
}

[bwoebi]

@arnaud-lb I definitely mentioned this in the past, but only discussions, no work on this.

function bar(mixed $obj) {}
bar($c); // what is the type of $c after that?

This has no effect at all with the proposed model. Only actual type assertions on $c will actually shrink the type.

So, yes, technically, a function bar() will be able to do whatever it wants with $obj and e.g. put it into a function accepting Collection<mixed> thereby locking the type.

But that's your fault. Either bar is a local function, where you can integrate bar into your reasoning, or it's an API function boundary, where it's your task to ensure that no operations freezing a type will happen. Just like you nowdays cannot accept function a(ParentClass $o) { b($o); } function b(Child $o) {} (or even simply function a(mixed $o) and expect that it works, just because the outer function accepts something more lax than it will actually forward.

---

There needs to be well-defined behaviour for type checks (i.e. instanceof) vs type assertions (function params).

$c = new C;
$c instanceof C<Foo>

and $value instanceof T inside a class C<T>

are indeed meaningless at that point.

These cases are also meaningless with static inference, unless there are specific types fed into it later ... unless static inference simply infers C or C then.

There are essentially three choices:

• inferring the maximal type
• inferring the minimal type
• erroring out (not enough info or such)

The safest thing to do it comparing against the min-type of the parameter here. (Meaning never on the first call) It's false for now, but maybe not in future - after all, from type theory, you cannot make any assumptions about the "everything minus something" set, only on actually constrained sets.

Note that new T and T::method are only possible without unions and intersections, and the former also only when T is not interface nor abstract class. We may decide to allow it, but it's a very specific bound to have. (e.g. T: class and T: new.)

These forcibly have to error out when not enough info is present. (as in, we inferred never and new never is not a thing.) It's a runtime condition, just like if you had code class C { public string $class; public function new() { return new ($this->class); } } ... as long as $class is not assigned, the code is meaningless, and thus obviously needs to error out.

---

I also would recommend to add a keyword on generic params C<require T> on classes which are intended to be using T directly without any value of type T passed in yet. To allow having it as part of the explicit contract rather than runtime weirdness, making it a guarantee by the callee that operations are safe.

[arnaud-lb]

@arnaud-lb I definitely mentioned this in the past, but only discussions, no work on this.

function bar(mixed $obj) {}
bar($c); // what is the type of $c after that?

This has no effect at all with the proposed model. Only actual type assertions on $c will actually shrink the type.

So, yes, technically, a function bar() will be able to do whatever it wants with $obj and e.g. put it into a function accepting Collection<mixed> thereby locking the type.

But that's your fault.

If the code just assumes that a mixed $c is in fact a Collection and uses it as such, I agree:

// This is invalid, and any static analyzer will error:

function bar(mixed $c) {
    $c->add('something');
}

However, this code would be valid, for example:

function serialize(mixed $c) {
    if ($c instanceof Collection) {
        return $this->collectionSerializer->serialize($c);
    } else if ...
}

Under progressive inference this will change the type of $c. It follows that we must assume that passing a generic object to a function may change its type.

There needs to be well-defined behaviour for type checks (i.e. instanceof) vs type assertions (function params).

$c = new C;
$c instanceof C<Foo>

and $value instanceof T inside a class C<T>

are indeed meaningless at that point.

These cases are also meaningless with static inference, unless there are specific types fed into it later ... unless static inference simply infers C or C then.

In reified generics, T should evaluate to the class bound to that type parameter. In erased generics, T is indeed meaningless.

There are essentially three choices:

* inferring the maximal type

* inferring the minimal type

* erroring out (not enough info or such)

The safest thing to do it comparing against the min-type of the parameter here. (Meaning never on the first call) It's false for now, but maybe not in future - after all, from type theory, you cannot make any assumptions about the "everything minus something" set, only on actually constrained sets.

IMHO, none of these alternatives are safe. The expected result of instanceof T should be the one when T is settled. But in all these alternatives, an instanceof expression may return different results while T is still being refined in ways the class can not control.

Note that new T and T::method are only possible without unions and intersections, and the former also only when T is not interface nor abstract class. We may decide to allow it, but it's a very specific bound to have. (e.g. T: class and T: new.)

Good point

These forcibly have to error out when not enough info is present. (as in, we inferred never and new never is not a thing.) It's a runtime condition, just like if you had code class C { public string $class; public function new() { return new ($this->class); } } ... as long as $class is not assigned, the code is meaningless, and thus obviously needs to error out.

In the case of new ($this->class) you can design $this such that $this->class is always an instantiatable class. That's not necessarily the case of new T().

I also would recommend to add a keyword on generic params C<require T> on classes which are intended to be using T directly without any value of type T passed in yet. To allow having it as part of the explicit contract rather than runtime weirdness, making it a guarantee by the callee that operations are safe.

This sounds reasonable. One caveat is that a class that was initially designed without require T can not start using T without BC break.

[bwoebi]

However, this code would be valid, for example:

function serialize(mixed $c) {
   if ($c instanceof Collection) {
       return $this->collectionSerializer->serialize($c);
   } else if ...
}

Under progressive inference this will change the type of $c. It follows that we must assume that passing a generic object to a function may change its type.

Can you explain to me how it affects the type of $c? Collection is the class - that doesn't change. It will only change the type of $c once you actually call a method receiving a T not fitting the current generics yet (it's then added to the min-types). Or once you actually check against a particular generic, which instanceof Collectiton does not.

IMHO, none of these alternatives are safe. The expected result of instanceof T should be the one when T is settled. But in all these alternatives, an instanceof expression may return different results while T is still being refined in ways the class can not control.

I would posit that min-type checking should be safe for most purposes as long as T isn't finalized (or required from the start) yet. As in: I think it's a reasonable default behaviour. When you need to do instanceof a fixed T, then you're required to provide it from the start.