Is there any reason to not allow ?A&B type?

PS: https://3v4l.org/mI6JY not allowed for |

Is there any reason to not allow ?A&B type?

PS: https://3v4l.org/mI6JY not allowed for |

Because it would be inconsistent with union types, also this makes for a bit of sigil soup and is hard to grasp what the meaning of this is, is it (?A)|B or ?(A&B), with explicit union types the second meaning is clearer to me as an intersection has higher precedence than a union but with ? the meaning I get is more (null|A)&B.

Therefore my reasoning is that is too confusing and will need to wait for composite types.

Thank you for working on this feature. I understand that you want to keep the first iteration simple and thus leave unions out of the PR.

However, if I'm not mistaken, you would create the only type that is not nullable. That feels like an unnecessary edge-case. Would it be very difficult to at least allow the union of an intersect type with null?

I think A&B|C and A&B|null should be allowed, there is no ambiguity, & always takes precedence over |.

UPDATE: I meant union of any number of (possibly purely intersected) types.

It has nothing to do with ambiguity but I see no point in supporting just A&B|C, it should either be full support for composite types (regardless of support for grouping) or none. As why limit it to A&B|C and not allow A&B|C&D or A&B|C|D|E it is just moving the goal post. And the moment you look into supporting A&B|C you most certainly will get support for the whole range of combination. As the issue is less about parsing nor type checking (as my initial prototype shows although far from done), but the variance rules and checks, it already needs a different nested loop order to traverse both the parent and the child type list just for the pure intersection type case, and at this time I haven't thought deeply about how to handle this nor have really any idea how to achieve this. As the largest part of this proposal has been figuring out how to perform this rather "simplistic" variance check.

Obviously support for full composite type is the end goal, however, I've clearly stated that this is future scope, it could even land in PHP 8.1 as a follow up either by myself or someone else. But I cannot guarantee that I'll get round to that prior to the end of June which is the likely cutoff date for getting an RFC included into PHP 8.1.

If internals decide the feature is incomplete so be it, but I prefer getting this restricted addition into the language upon which one can iterate instead of having perfectness being the enemy of the good.

This is brilliant! Regarding composite types and variance... should mixing intersections and unions be allowed in inheritance at this stage? E.g. the following code which I believe is valid from the LSP perspective:

interface X {}
interface Y {}

class TestOne implements X, Y {}
class TestTwo implements X, Y {}

class A
{
    public function foo(TestOne|TestTwo $param): X&Y {}
}

class B extends A
{
    public function foo(X&Y $param): TestOne|TestTwo {}
}

This is brilliant! Regarding composite types and variance... should mixing intersections and unions be allowed in inheritance at this stage? E.g. the following code which I believe is valid from the LSP perspective:

interface X {}
interface Y {}

class TestOne implements X, Y {}
class TestTwo implements X, Y {}

class A
{
    public function foo(TestOne|TestTwo $param): X&Y {}
}

class B extends A
{
    public function foo(X&Y $param): TestOne|TestTwo {}
}

that's a really good question, personally i think the following should be allowed at this stage.

interface X {}
interface Y {}

class TestOne implements X, Y {}
class TestTwo implements X, Y {}

interface A
{
    public function foo(TestOne|TestTwo $param): X&Y;
}

interface B extends A
{
    public function foo(X&Y $param): TestOne|TestTwo;
}

interface C extends A
{
    public function foo(X $param): TestTwo;
}

interface D extends A
{
    public function foo(Y $param): TestOne;
}

interface E extends B
{
    public function foo(X $param): TestTwo;
}

interface F extends B
{
    public function foo(Y $param): TestOne;
}

This is brilliant! Regarding composite types and variance... should mixing intersections and unions be allowed in inheritance at this stage? E.g. the following code which I believe is valid from the LSP perspective:

interface X {}
interface Y {}

class TestOne implements X, Y {}
class TestTwo implements X, Y {}

class A
{
    public function foo(TestOne|TestTwo $param): X&Y {}
}

class B extends A
{
    public function foo(X&Y $param): TestOne|TestTwo {}
}

that's a really good question, personally i think the following should be allowed at this stage.

interface X {}
interface Y {}

class TestOne implements X, Y {}
class TestTwo implements X, Y {}

interface A
{
    public function foo(TestOne|TestTwo $param): X&Y;
}

interface B extends A
{
    public function foo(X&Y $param): TestOne|TestTwo;
}

interface C extends A
{
    public function foo(X $param): TestTwo;
}

interface D extends A
{
    public function foo(Y $param): TestOne;
}

interface E extends B
{
    public function foo(X $param): TestTwo;
}

interface F extends B
{
    public function foo(Y $param): TestOne;
}

You'll be happy to learn that this worked without any modification :-) (which means I probably got most of the variance code correct)

The variance implementation looks wrong to me, but it took me quite a while to figure out why. Consider:

<?php

class X {}
class Y {}
class Z {}

class A {
    public function test(): X|Z {}
}
class B extends A {
    public function test(): X&Y {}
}

I believe this should pass, because X&Y is a subtype of X is a subtype of X|Z, but currently is rejected, because you're effectively treating the parent type as X&Z.

@nikic

I think the example you gave should error, but for a different reason, that is it's impossible to have X&Y type, since they are both classes, you can't create a new class which extends both, but it should work with interfaces.

@nikic

I think the example you gave should error, but for a different reason, that is it's impossible to have X&Y type, since they are both classes, you can't create a new class which extends both, but it should work with interfaces.

Change the classes to interfaces and the problem is still there, and obviously it will error during Runtime because it can't satisfy two classes, but we do not know this at compile time.

The variance code seems correct to me, the only thing which felt weird was the need to load classes when object is in the parent type, so I moved that branch out.

@Girgias Loading classes for object type is necessary for forward-compatibility with type aliases. We do the same thing for other object variance checks.

Okay, I'll revert and add a comment to make sure that doesn't get reworked.