On 22/05/15 01:19, Stanislav Malyshev wrote:
>> > I'd like to add "void" to this list, so we have the option to introduce a
>> > void return type in PHP 7.x. I've seen some disagreement as to whether this
> I think this type makes no sense in PHP, but I don't object to having
> note in the docs for
On May 22, 2015 7:20 AM, "Stanislav Malyshev" wrote:
>
> Hi!
>
> > I'd like to add "void" to this list, so we have the option to introduce
a
> > void return type in PHP 7.x. I've seen some disagreement as to whether
this
>
> I think this type makes no sense in PHP, but I don't object to having
> n
Hi!
> I'd like to add "void" to this list, so we have the option to introduce a
> void return type in PHP 7.x. I've seen some disagreement as to whether this
I think this type makes no sense in PHP, but I don't object to having
note in the docs for people not to name their classes "void" (not tha
Hi,
I think that not reserving "void" by spec now is actually going against the
"Request For Comments" process. If we don't soft reserve now we won't even
have the possibility to discuss it later, this kills the discussion before
it starts.
The soft reservation has zero impact over PHP7.0, no one
On May 21, 2015 6:45 PM, wrote:
>
> Hi,
>
> > De: "Nikita Popov"
> >
> > For PHP 7 we soft-reserved a number of class names [1] like "numeric",
so
> > that we have the ability to introduce them as typehints in a 7.x
release.
> > "Soft" here means that we only document these names as being reserve
Hi,
> De: "Nikita Popov"
>
> For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
> that we have the ability to introduce them as typehints in a 7.x release.
> "Soft" here means that we only document these names as being reserved and
> don't throw an error when they're used.
On Tue, May 19, 2015 at 9:16 AM, Levi Morrison wrote:
> I strongly disagree with this action. These types required an RFC; why
> should this be different? Also note that neither of the reserve
> typename RFC were unanimous.
>
> Furthermore, we are past the RFC stage. We are *supposed to already
>
On 19 May 2015 17:21:58 BST, Levi Morrison wrote:
>On a related note it is unclear what BC breaks are exactly allowed in
>minor releases. Adding new reserved types is a BC break, but it was
>done in PHP 5.4 with `callable`. We should solidify what we do and do
>not allow in minor releases for the
On 19 May 2015 at 17:16, Levi Morrison wrote:
> I strongly disagree with this action. These types required an RFC; why
> should this be different? Also note that neither of the reserve
> typename RFC were unanimous.
>
> Furthermore, we are past the RFC stage. We are *supposed to already
> have an
On Tue, May 19, 2015 at 10:16 AM, Levi Morrison wrote:
> I strongly disagree with this action. These types required an RFC; why
> should this be different? Also note that neither of the reserve
> typename RFC were unanimous.
>
> Furthermore, we are past the RFC stage. We are *supposed to already
>
I strongly disagree with this action. These types required an RFC; why
should this be different? Also note that neither of the reserve
typename RFC were unanimous.
Furthermore, we are past the RFC stage. We are *supposed to already
have an alpha* by now and we are proposing new changes?. Please st
On Tue, May 19, 2015 at 5:28 PM, Nikita Popov wrote:
> Hi internals!
>
> For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
> that we have the ability to introduce them as typehints in a 7.x release.
> "Soft" here means that we only document these names as being reserved an
+1
Hi internals!
For PHP 7 we soft-reserved a number of class names [1] like "numeric", so
that we have the ability to introduce them as typehints in a 7.x release.
"Soft" here means that we only document these names as being reserved and
don't throw an error when they're used.
I'd like to add "void
14 matches
Mail list logo
