Hi internals
I wanted to apologise for the poor wording I used in my previous mail when I
said "oversight". What I meant to say is what Nicolas described in his followup
mail: feature freeze as a time to polish implementations. I personally consider
nullability to be more of an implementation
On Wed, Jul 28, 2021, 05:26 Pierre Joye wrote:
>
However my question was more about the rush for it, those are not easy to
> implement nicely, given the actual use cases, I am not sure it was worth
> this hurry. And I have the same feeling for this discussion about nullable
> intersection.
>
My
Hi Jordan,
On Wed, Jul 28, 2021, 10:02 AM Jordan LeDoux
wrote:
> Intersection types are very useful if you use composition over
> inheritance. That is, in PHP, they are most useful when you are using
> multiple interfaces and/or traits to represent different aspects of an
> object which might
Intersection types are very useful if you use composition over inheritance.
That is, in PHP, they are most useful when you are using multiple
interfaces and/or traits to represent different aspects of an object which
might be present. For example, using an actual library I maintain, I have a
Good morning,
On Wed, Jul 28, 2021 at 5:52 AM Rowan Tommins wrote:
>
> On 27 July 2021 21:29:47 BST, "André Hänsel" wrote:
> >> In fact, when 7.1 was released, none of the signatures changed in my
> >code, they were just
> >> updated to a different syntax.
> >
> >That by the way is only because
On 27 July 2021 21:29:47 BST, "André Hänsel" wrote:
>> In fact, when 7.1 was released, none of the signatures changed in my
>code, they were just
>> updated to a different syntax.
>
>That by the way is only because of a specific compatibility behavior
>which is so confusing
>that I erroneously
> In fact, when 7.1 was released, none of the signatures changed in my code,
> they were just
> updated to a different syntax.
That by the way is only because of a specific compatibility behavior which is
so confusing
that I erroneously reported it as a bug:
> - PHP 7.0 types were a pain because of non-nullable types, the feature
only became really useful as of PHP 7.1
See, this keeps being said, but as another userland developer it's
extremely confusing. The types in 7.0 were very useful, and I personally
didn't notice at all that they were missing
Hi all
From a userland developer point of view:
- PHP 7.0 types were a pain because of non-nullable types, the feature only
became really useful as of PHP 7.1
- I share many people's opinion that this falls in the category of oversight
- I think (A)|null is the only sensible way to go
On 27/07/2021 14:32, Brent Roose wrote:
From a userland developer point of view:
- PHP 7.0 types were a pain because of non-nullable types, the feature only
became really useful as of PHP 7.1
You're not the only person to say this, but I find it really hard to
believe.
If this was so
On 23.07.21 11:58, Nicolas Grekas wrote:
Hi everyone,
as proposed by Nikita and Joe, I'm submitting this late RFC for your
consideration for inclusion in PHP 8.1. Intersection types as currently
accepted are not nullable. This RFC proposes to make them so.
I wrote everything down about the
On Fri, Jul 23, 2021 at 4:58 AM Nicolas Grekas
wrote:
> https://wiki.php.net/rfc/nullable_intersection_types
>
>
I've commented on the PR and in R11 a bit already, but I'd like to state my
position here for the record. I do see the value in having nullability,
but I can't disagree enough with
On Sat, Jul 24, 2021, at 12:33 AM, Tobias Nyholm wrote:
> >> @Larry makes an argument to keep them:
> >>
> >>> Requiring parenthesis now leaves the option open in the future to make
> >>> them optional when doing full mixed types.
> >>
> >>
> >> I don’t understand why we should require
On Fri, Jul 23, 2021, 11:58 Nicolas Grekas wrote:
> Hi everyone,
>
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
> consideration for inclusion in PHP 8.1. Intersection types as currently
> accepted are not nullable. This RFC proposes to make them so.
>
> I wrote
> That is a strange attitude. You are saying that you rather see a release with
> a [known] flaw than actually trying to find the best solution.
Sorry, but sometimes features take time either due to technical
reasons (variance was difficult to get right this way), or due to
disagreements in
This is not a new feature. This is a detail of a feature that was not well
understood for whatever reason.
That is why we are willing to fix it after freeze.
I would ask anyone voting to vote on the basis of the detail and leave
timing to be the problem of release managers. Voting negatively
> On Jul 24, 2021, at 1:33 AM, Tobias Nyholm wrote:
>> If you are not willing to compromise you will probably get nothing.
>>
>> It is relevant because I was trying to get you to ask yourself if you would
>> be happier if you get half of what you want rather than none of what you
>> want.
>>
On Sat, Jul 24, 2021, 07:33 Tobias Nyholm wrote:
>
> >>> Given both of these sets of assertions I would ask the RFC's author
> and proponents what would be a worse outcome?
> >>
> >> I don’t see how this question is relevant. We are not seeking
> compromises at the moment. We are seeking the
I do not think this is strictly true. The issue that this RFC is running
into is that combination types between intersections and unions was
something that was avoided for the intersection types RFC. Not because the
authors never thought of it, but because the RFC would have become very
broad and
>> @Larry makes an argument to keep them:
>>
>>> Requiring parenthesis now leaves the option open in the future to make them
>>> optional when doing full mixed types.
>>
>>
>> I don’t understand why we should require something that is not needed simply
>> because it would give us an option
> On Jul 24, 2021, at 12:42 AM, Tobias Nyholm wrote:
>
>> It seems this RFC is actually trying to accomplish two(2) things:
>>
>> 1. Add typehints for nullable intersection types to PHP.
>> 2. Get PHP to support a preferred syntax for type-hinting nullable
>> intersection types.
>
> Yes of
> It seems this RFC is actually trying to accomplish two(2) things:
>
> 1. Add typehints for nullable intersection types to PHP.
> 2. Get PHP to support a preferred syntax for type-hinting nullable
> intersection types.
Yes of course. You cannot really do #1 without #2.
I agree with Nicolas
> On Jul 23, 2021, at 5:58 AM, Nicolas Grekas wrote:
>
> Hi everyone,
>
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
> consideration for inclusion in PHP 8.1. Intersection types as currently
> accepted are not nullable. This RFC proposes to make them so.
>
> I wrote
Le 23/07/2021 à 18:25, Larry Garfield a écrit :
Requiring parenthesis now leaves the option open in the future to make them
optional when doing full mixed types.
Making them optional now requires that they be optional in the future when
doing full mixed types.
I vaguely recall there being
On Fri, Jul 23, 2021, at 11:06 AM, Pierre wrote:
> Le 23/07/2021 à 17:56, Levi Morrison via internals a écrit :
> >> As you note in the RFC, PHP already defines `|` as having a lower
> >> precedence than `&`, so `X & Y | null` can only be interpreted as
> >> `(X & Y) | null`. This is consistent
Le 23/07/2021 à 17:56, Levi Morrison via internals a écrit :
As you note in the RFC, PHP already defines `|` as having a lower
precedence than `&`, so `X & Y | null` can only be interpreted as
`(X & Y) | null`. This is consistent with other languages such as
TypeScript, where `A & B | C & D` is
> As you note in the RFC, PHP already defines `|` as having a lower
> precedence than `&`, so `X & Y | null` can only be interpreted as
> `(X & Y) | null`. This is consistent with other languages such as
> TypeScript, where `A & B | C & D` is parsed as `(A & B) | (C & D)`.
> [2]
>
> Since
On Friday, July 23, 2021 at 4:58 AM Nicolas Grekas
wrote:
> Hi everyone,
>
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
> consideration for inclusion in PHP 8.1. Intersection types as currently
> accepted are not nullable. This RFC proposes to make them so.
>
> I wrote
On Fri, Jul 23, 2021 at 4:31 PM Deleu wrote:
> On Fri, Jul 23, 2021 at 2:36 PM Derick Rethans wrote:
>
> > From the RFC: «Taking all these elements into account, the preference
> > of... and thus to use the "?X" syntax».
> >
> > I think this would be a mistake. You touch upon operator
On Fri, Jul 23, 2021 at 2:36 PM Derick Rethans wrote:
> From the RFC: «Taking all these elements into account, the preference
> of... and thus to use the "?X" syntax».
>
> I think this would be a mistake. You touch upon operator precedence, and
> needing to know whether | or & is higher, and
On Fri, Jul 23, 2021 at 6:37 AM Derick Rethans wrote:
>
> From the RFC: «Taking all these elements into account, the preference
> of... and thus to use the "?X" syntax».
>
> I think this would be a mistake. You touch upon operator precedence, and
> needing to know whether | or & is higher, and
> > as proposed by Nikita and Joe, I'm submitting this late RFC for your
> > consideration for inclusion in PHP 8.1. Intersection types as
> > currently accepted are not nullable. This RFC proposes to make them
> > so.
> >
> > I wrote everything down about the reasons why here:
> >
On Fri, 23 Jul 2021, Nicolas Grekas wrote:
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
> consideration for inclusion in PHP 8.1. Intersection types as
> currently accepted are not nullable. This RFC proposes to make them
> so.
>
> I wrote everything down about the
Le ven. 23 juil. 2021 à 13:05, Guilliam Xavier
a écrit :
>
> On Fri, Jul 23, 2021 at 11:58 AM Nicolas Grekas
> wrote:
>
>> Hi everyone,
>>
>> as proposed by Nikita and Joe, I'm submitting this late RFC for your
>> consideration for inclusion in PHP 8.1. Intersection types as currently
>>
On Fri, Jul 23, 2021 at 11:58 AM Nicolas Grekas
wrote:
> Hi everyone,
>
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
> consideration for inclusion in PHP 8.1. Intersection types as currently
> accepted are not nullable. This RFC proposes to make them so.
>
> I wrote
35 matches
Mail list logo
