[RFC] [Discussion] Never parameters View as Markdown

I would also personally prefer associated types: ... This at least lets you ensure the "other point" is the same type in both functions, though personally, I'd rather just have generics.

I'd also like to have generics, but that isn't something I can implement myself. Associated types would be interesting, but I don't think that associated types would remove the entire use-case for never parameters, just perhaps the specific example of BackedEnum.

---

• Daniel

Heh, this is the long game I am playing with inner classes: https://externals.io/message/125049#125057

If inner classes can be implemented, then we are just a short hop from being able to implement generics with a similar approach to what I outlined in that thread. Granted, I'm making some major changes to the RFC at the moment and the implementation -- based on feedback, so it'll be a few days before that is finished.

An inner class view of generics (as opposed to the type aliasing view in that thread) looks something like this:

// Box<T>
class Box {
public class T {}

// store(T $item)
public function store(static:>T $item) {}
}

// new Box<ItemType>()
$box = new class() extends Box {
public class ItemType as T {}
};

-Ish. Note that the example won’t actually work; but it illustrates how the engine could implement it if there were inner/nested types.

So, assuming this new implementation I’ve been working on is waaay better than the old one (I think it is), and the RFC is accepted; we may be closer to generics than you thought. Or maybe there is someone out there with a whole different way of doing it that is even better… This is the approach I'm chasing though.

— Rob

Hi

Am 2025-03-11 22:45, schrieb Larry Garfield:

We should not block this kind of improvement on the hope of generics.
Worst case, we have this plus generics so you have options, how
terrible.

In this case, I agree. This is an obvious addition to the type system
that uses the existing infrastructure of the type system.

But generally speaking, having too many options is not a good thing. It
makes the language larger and more complex to learn, requires
documentation effort, support by IDEs and static analyzers and similar
things.

It's definitely a balancing act, yes. TIMTOWTDI definitely has downsides, but at the same time, having multiple ways to accomplish the same goal isn't inherently wrong, unless they conflict with each other in some way.

Rust-style associated types would probably work as well. I'd be fine
with that approach, too. One could argue they're more valuable as a
sort of "junior generics," but absent anyone able and willing to
implement them, again, worst-case we end up with options in the future.

… so for associated types, I do not necessarily agree. They seem to be a
strict subset of the functionality enabled by generics, or the
functionality enabled by type aliases combined with “inner classes /
inner types”. Since introducing associated types would bring entirely
new syntax and semantics to the language, it is less obvious to me that
they are a useful (intermediate) addition to the language.

The counter argument here is that a number of languages (like Rust) have both generics and associated types, so they can coexist and serve slightly different use cases. I have not used Rust enough to have an opinion on how and when to use one or the other, but having one doesn't seem to impede the other.

From my (admittedly limited) understanding, associated types sounds rather like the "inheritance only" pseudo-generics that Derick had proposed for collections last year, in a more general form. (cf: https://thephp.foundation/blog/2024/08/19/state-of-generics-and-collections/#collections)

--Larry Garfield

As the person that had the initial discussion in R11 with Jordan [1]
never as a parameter type for an interface actually is not the solution
for "poor man generics".
Matthew Fonda [2] already replied to the thread pointing out the remark
Nikita made in the discussion of the previous RFC.
But importantly, going from mixed parameter type to a generic parameter
type is allowed and not a BC change,
however, going from a never parameter type to a generic parameter type
is a BC break.

To clarify, you're saying this:

interface I {
pubic function foo(mixed $a);
}
class C implements I {
public function foo(mixed $b) { ... }
}

Can turn into this:

interface I<A> {
pubic function foo(A $a);
}
class C implements I<Foo> {
public function foo(Foo $b) { ... }
}

But this could not turn into that:

interface I {
pubic function foo(never $a);
}
class C implements I {
public function foo(Foo $b) { ... }
}

Am I following that? Because just from writing that I am not sure I agree, which means I may be misunderstanding. :-)

--Larry Garfield

I have a use case for this in Serde, so would be in favor.

We should not block this kind of improvement on the hope of generics. Worst case, we have this plus generics so you have options, how terrible.

Would you mind sharing details of your Serde use case? It seems that
the BackedEnum example might not have been the best (since it is for
static methods) and so perhaps a userland case where this would be used
would help.

--Daniel

Simplified example to show the thing we care about:

I have an interface Formatter, like:

interface Formatter
{
public function serializeInitialize(ClassSettings $classDef, Field $rootField): mixed;

public function serializeInt(mixed $runningValue, Field $field, ?int $next): mixed;

public function serializeFloat(mixed $runningValue, Field $field, ?float $next): mixed;

// And other methods for other types
}

The $runningValue is of a type known concretely to a given implementation, but not at the interface level. It's returned from serializeIntialize(), and then passed along to every method, recursively, as it writes out an object.

So for instance, the JSON formatter looks like this:

class JsonSerializer implements Formatter
{
public function serializeInitialize(ClassSettings $classDef, Field $rootField): array
{
return ['root' => []];
}

/**
 * @param array<string, mixed> $runningValue
 * @return array<string, mixed>
 */
public function serializeInt(mixed $runningValue, Field $field, ?int $next): array
{
    $runningValue[$field->serializedName] = $next;
    return $runningValue;
}

}

Because JsonFormatter works by building up an array and passing it to json_encode(), eventually. So $runningValue is guaranteed to always be an array. I can narrow the return value to an array, but not the parameter.

The JsonStreamFormatter, however, has a stream object that it passes around (which wraps a file handle internally):

class JsonStreamFormatter implements Formatter
{
public function serializeInitialize(ClassSettings $classDef, Field $rootField): FormatterStream
{
return FormatterStream::new(fopen('php://temp/', 'wb'));
}

/**
* @param FormatterStream $runningValue
*/
public function serializeInt(mixed $runningValue, Field $field, ?int $next): FormatterStream
{
$runningValue->write((string)$next);
return $runningValue;
}
}

Again, I can narrow the return value but not the param.

To be clear, generics would absolutely be better in this case. I'm just not holding my breath.

Associated Types would probably work in this case, too, since it's always relevant when creating a new concrete object, not when parameterizing a common object. If we got that, I'd probably use that instead.

Changing the interface to use never instead of mixed would have the weakest guarantees of the three, since it doesn't force me to use the same widened type on serializeInt(), serializeFloat(), serializeString(), etc., even though it would always be the same. But it would allow me to communicate more type information than I can now.

How compelling this use case is, I leave as an exercise for the reader.

--Larry Garfield

The original inspiration which I discussed in the RFC is fixing the
signature of the BackedEnum methods, which currently use the second
option.

Hey,

I'm not opposed to having a bottom type, but the try/tryFrom issue
feels caused by another shortcoming.

In my viewfrom and tryFrom are factory methods that construct an
instance by being called on the class itself. As such they should not be
subject to LSP at all, just like __construct is not.

BR,
Juris

On Thu, Mar 20, 2025 at 9:51 AM Daniel Scherzer daniel.e.scherzer@gmail.com
wrote:

On Sun, Mar 16, 2025 at 12:31 PM Matt Fonda matthewfonda@gmail.com
wrote:

Hi Daniel,

I believe this feature essentially amounts to "add methods which can
never be called", which in my mind makes no sense. If a method types
against an interface, and that interface uses a method with a never
parameter type, then we cannot actually call that method. We'd need to know
the specific concrete type, which defeats the purpose of using an interface
in the first place.

First, I would point out that I tried to make this limited to methods that
already cannot be called - only to interfaces and abstract methods. You
already can't call those directly, you need to have a subclass. And you can
always type against the implementation with the actual methods that are not
never-typed.

To clarify, what I mean by calling methods on an interface is typing
against the interface (for example, as a parameter to a method/function)
and then calling methods defined by the interface. As users of the
interface, we can call methods on it without knowing or caring which
specific subclass we're actually working with. In my mind, this is the
entire point of interfaces. We can write code like the following:

function foo(SomeInterface $i) {
// ... call $i->someMethod();
}

Within foo, all we know is that $i is an instance of SomeInterface. We can
call any method on $i that SomeInterface defines. If one of those methods
had a never argument, then we could never call it.

If we did want to call the method with a never argument, then we'd need to
know a specific subclass and what type it overrides never with. At that
point, we're no longer using the interface; we're instead using the
specific subclass, entirely eliminating the need for the interface in the
first place.

So I would ask - if not never parameters, then what should users do? It
seems like, for the use case of "the interface adds a method but there are
no promises about what parameters it accepts"

If an interface adds a method but makes no promises about what parameters
it accepts, then why is it part of the interface in the first place--why
add a method that can't be used?

Best regards,
--Matthew

On Tue, 15 Apr 2025 at 20:59, Daniel Scherzer
daniel.e.scherzer@gmail.com wrote:

Since a lot of the discussion seems to be around static analysis and whether there is a real use case for this, I wanted to share another use case I just came across: in the thephpleague/commonmark package, different renderers are added to render different types (subclasses) of League\CommonMark\Node\Node.

I added this example to the RFC page as an example of how this could be useful in userland code. Barring further developments, I plan to open the RFC for voting in a few days.

-Daniel

Thank you,
I have been wanting this since a long time!
https://externals.io/message/100275

One interesting application is intersection types.
https://externals.io/message/115712#123276
The intersection of different types with "never" parameters and
"mixed" return types naturally produces a valid new type:
(function(A, never): mixed) & (function(never, B): mixed) &
(function(never, never): R) === function (A, B): R
(imagine all of the above to be interfaces)

An interesting question I wonder is whether we would ever want
"constrained never" parameters.
E.g. currently we can have an interface I with function (A&B), where A
and B are classes/interfaces.
A sub-interface J that extends I can have function (A) or function (B)
or function (mixed) or function (A|SomethingElse).
But it cannot have function (C), if neither A nor B extends C.

In the same way, for function(int&string), a child method would have
to allow at least int or string, e.g. it cannot be function(float) or
function(C).
(it could be extended as function(int|float) or function(mixed), but
not function(float).)
So in a way this could be a more suitable parameter type for
BackedEnum::from() and ::tryFrom().

For the main part of this RFC we do not need to worry about this.
For the BackedEnum::from() and ::tryFrom(), if we change the type to
'never' now, we can no longer change it to int&string later without
breaking BC.

Another thing I wonder is whether the "Proposal" section needs to more
explicitly define the behavior.
Can we rely on the "Introduction" part and the examples in other
sections, or does the "Proposal" part need to be complete and
sufficient by itself?

What would we add, and what would be redundant?

"A method with a never parameter cannot be called."
This already follows from "it cannot be used in the declaration of any
method that has an implementation.", so we do not need to explicitly
add it.

"The never parameter type can only be used standalone, not as part of
a union or intersection or nullable type".
This might already be specified elsewhere, where never is defined as a
return type.

"A child class or interface that overrides a method with a never
parameter can replace the never parameter type with any other type, or
omit the parameter type altogether."
This is obvious to us from LSP, but do we need to explicitly define it?
It is currently mentioned in "Introduction" but not in "Proposal".

"A child class or interface that overrides a method with a never
parameter must respect LSP for the other parameters."
So, you cannot extend a function(A, never) with function(never, never).
I think this is pretty clear from general rules about covariance/contravariance.

So the only point that might make sense to add is the third one about
widening the type.

-- Andreas