Hello list,
to revive this old RFC.
One really nice application of never parameters is with intersection types:
interface I {}
interface ReturnI {
public function foo(never $x): I;
}
interface AcceptI {
public function foo(I $x): mixed;
}
function f(ReturnI $arg, I $x): I {
return
On Sat, 14 Aug 2021 at 15:05, Larry Garfield wrote:
>
> On Sat, Aug 14, 2021, at 7:48 AM, G. P. B. wrote:
> > On Sat, 14 Aug 2021 at 10:55, Deleu wrote:
> >
> > > Hi Jordan,
> > >
> > > Does it make sense to explain in the RFC the difference between never and
> > > mixed in this context? The RFC
Hey all,
Thanks for the feedback and the engagement on this RFC. I'll be withdrawing
this RFC as it's clear that its drawbacks are too large for the benefits it
does provide from internals' perspective. Essentially, I saw a very small
and safe change that could be made to the engine that would
On Mon, Aug 16, 2021 at 12:51 AM Nikita Popov wrote:
> We have a better way to specify markers for the engine: Magic methods. I
> think some people have a mistaken notion that engine-integrated interfaces
> are always better than magic methods. This is only the case if such
> interfaces are
On Aug 16 2021, at 1:21 pm, Nikita Popov wrote:
> On Sat, Aug 14, 2021 at 3:44 PM Jordan LeDoux
> wrote:
>
> >
> >
> > On Sat, Aug 14, 2021 at 6:25 AM Nikita Popov wrote:
> >
> >>
> >> function addMultiple(CollectionInterface $collection, mixed ...$inputs):
> >> void {
> >> foreach ($inputs as
On Sat, Aug 14, 2021 at 3:44 PM Jordan LeDoux
wrote:
>
>
> On Sat, Aug 14, 2021 at 6:25 AM Nikita Popov wrote:
>
>>
>> function addMultiple(CollectionInterface $collection, mixed ...$inputs):
>> void {
>> foreach ($inputs as $input) $collection->add($input);
>> }
>>
>> A static analyzer
On Sun, Aug 15, 2021 at 4:06 PM Alexandru Pătrănescu
wrote:
> Hey Jordan,
>
> From type perspective, this sounds good.
>
> But, in my view, types should be checked statically.
> For inheritance, when defining a method, both the parameters and return
> types are nicely checked statically and
> On Aug 15, 2021, at 7:06 PM, Alexandru Pătrănescu wrote:
>
> If I see an interface that was created just so it can be implemented by
> multiple classes but the caller doesn't use the interface but it uses the
> actual classes, I call it out as that is the wrong abstraction and the
> interface
On Sat, Aug 14, 2021, 01:27 Jordan LeDoux wrote:
> Hey internals,
>
> I've been working on the draft for my operator overloading RFC, and in
> doing so I encountered a separate change that I would like to see.
>
> That is, the use of `never` as an argument type for interfaces. Since
> arguments
On Sun, Aug 15, 2021 at 1:11 PM Jordan LeDoux
wrote:
>
> So your intuition is correct. `foo(never $something)` will result in a
> `TypeError` if you try to call it directly. The only way it can be called
> is by being overridden with a wider type, which is why most of the focus is
> around
On Sun, Aug 15, 2021 at 3:43 AM Lynn wrote:
> On Sat, Aug 14, 2021 at 1:27 AM Jordan LeDoux
> wrote:
>
>>
>> Any feedback is greatly appreciated.
>>
>
> https://github.com/JordanRL/never-argument-type
>
>
> My only feedback is that it should not be called `never`. If I see `never`
> as the
On Sun, Aug 15, 2021, 12:43 Lynn wrote:
> My only feedback is that it should not be called `never`. If I see `never`
> as the parameter type, I read this as never being allowed to pass anything,
> which means that `foo('something')` with `foo(never $something)` will
> result in a compile error.
On Sat, Aug 14, 2021 at 1:27 AM Jordan LeDoux
wrote:
>
> Any feedback is greatly appreciated.
>
https://github.com/JordanRL/never-argument-type
My only feedback is that it should not be called `never`. If I see `never`
as the parameter type, I read this as never being allowed to pass
On Sun, Aug 15, 2021 at 1:25 AM Ondřej Mirtes wrote:
> It’s true that having “never” in a parameter type (please use “parameter”
> name for the method declaration, “argument” is what you pass to a parameter
> when you call the method) would allow to use any type in an overriding
> method from
It’s true that having “never” in a parameter type (please use “parameter”
name for the method declaration, “argument” is what you pass to a parameter
when you call the method) would allow to use any type in an overriding
method from contravariance/LSP point of view. But at the same time the
> On Aug 14, 2021, at 10:40 AM, Jordan LeDoux wrote:
>
> Never is treated as the bottom type for the purpose of Liskov substitution
> already with its use as a return type. The exception to this in its use as
> a return type is that it isn't treated as the union identity in the return
> type.
On Sat, Aug 14, 2021 at 10:12 AM Claude Pache
wrote:
>
> If users of that interface would suddenly be *required* to specify a
> parameter type, whereas previously they were *forbidden* to specify one,
> except a meaningless `mixed`... it would be not nice and useless.
>
> Moreover, note that
>
> On Fri, 13 Aug 2021 at 19:27, Jordan LeDoux wrote:
>
>> Hey internals,
>>
>> I've been working on the draft for my operator overloading RFC, and in
>> doing so I encountered a separate change that I would like to see.
>>
>> That is, the use of `never` as an argument type for
Hey!
Using the "never" type to require that downstream libs specify a type does
not make intuitive sense to me, because the same is not true the other way
(covariantly) for return types.
The existence of a "never" type on an overriding method does not require
that upstream libs specify a return
The RFC has been moved to the wiki:
https://wiki.php.net/rfc/never_for_parameter_types
The most critical points of discussion in my mind are:
1. Should never require **explicit** widening as discussed? This could be
very useful but would make it the only case in PHP where omitting a type is
not
On Sat, Aug 14, 2021 at 7:01 AM AllenJB wrote:
>
> Whilst I understand there's a historical aspect to the keyword naming
> used in this RFC, as a PHP developer, I think the use of "never" here is
> going to be confusing to people when considered along-side the never
> return type.
>
> I think it
On Sat, 14 Aug 2021 at 16:01, AllenJB wrote:
> This RFC only considers this feature for arguments. Why is it also not a
> valid feature for return types? I think it might be useful for abstract
> classes and interfaces (for example, the Iterator interface) to force
> implementers to specify a
On 14/08/2021 00:27, Jordan LeDoux wrote:
Hey internals,
I've been working on the draft for my operator overloading RFC, and in
doing so I encountered a separate change that I would like to see.
That is, the use of `never` as an argument type for interfaces. Since
arguments in PHP are
On Sat, Aug 14, 2021 at 6:25 AM Nikita Popov wrote:
>
> function addMultiple(CollectionInterface $collection, mixed ...$inputs):
> void {
> foreach ($inputs as $input) $collection->add($input);
> }
>
> A static analyzer should flag this CollectionInterface::add() call as
> invalid, because
On Sat, Aug 14, 2021 at 1:27 AM Jordan LeDoux
wrote:
> Hey internals,
>
> I've been working on the draft for my operator overloading RFC, and in
> doing so I encountered a separate change that I would like to see.
>
> That is, the use of `never` as an argument type for interfaces. Since
>
On Sat, Aug 14, 2021, 14:48 G. P. B. wrote:
> On Sat, 14 Aug 2021 at 10:55, Deleu wrote:
>
>> Hi Jordan,
>>
>> Does it make sense to explain in the RFC the difference between never and
>> mixed in this context? The RFC vaguely mentions that never can never be
>> used directly, but if it's
On Sat, Aug 14, 2021, at 7:48 AM, G. P. B. wrote:
> On Sat, 14 Aug 2021 at 10:55, Deleu wrote:
>
> > Hi Jordan,
> >
> > Does it make sense to explain in the RFC the difference between never and
> > mixed in this context? The RFC vaguely mentions that never can never be
> > used directly, but if
On Sat, 14 Aug 2021 at 10:55, Deleu wrote:
> Hi Jordan,
>
> Does it make sense to explain in the RFC the difference between never and
> mixed in this context? The RFC vaguely mentions that never can never be
> used directly, but if it's limited to abstract class and interfaces, isn't
> that
Hi Jordan,
Does it make sense to explain in the RFC the difference between never and
mixed in this context? The RFC vaguely mentions that never can never be
used directly, but if it's limited to abstract class and interfaces, isn't
that already impossible to use directly? Or does it mean that the
Hey internals,
I've been working on the draft for my operator overloading RFC, and in
doing so I encountered a separate change that I would like to see.
That is, the use of `never` as an argument type for interfaces. Since
arguments in PHP are contravariant to preserve Liskov substitution,
30 matches
Mail list logo
