On Sat, 3 Apr 2021 at 22:29, David Rodrigues wrote:
> It is very likely that the proposal will be accepted (it is already 33/10),
>
I'm definitely not counting my chickens.
> Is there any chance of discussing terms, even if the "never" indication is
> winning at the moment? Or did I miss this
Just to spice up the discussion a bit, I will try to give my opinion on
this RFC...
It is very likely that the proposal will be accepted (it is already 33/10),
but I still find the terms "noreturn" or "never" unclear. "noreturn" are
two words together, and I am not particularly a fan of this type
On Sat, 3 Apr 2021 at 12:30, Benjamin Eberlei wrote:
>
> But adding a new keyword "noreturn" would not be necessary, it could just
> be an Attribute as i said in my first e-mail explaining my no-vote:
>
> #[NoReturn] // sets a function flag modifying the void behavior
> public function foo(): not
Personally, I am against the syntax used in the PR for composite
types( even tho i don't have voting powers ).
I would prefer a syntax similar to Hack, where you have to use parentheses to
make things more explicit.
considering the following Hack code:
interface A {}
interface B {}
On 03.04.21 21:26, Peter Bowyer wrote:
This and Levi's email make compelling arguments and I would like to see
this adopted. I have changed my vote to "No".
Wasn't Levi arguing for the RFC? Introducing "never" as a bottom type is
what Levi was strongly arguing for, and that is what the RFC curre
On Sat, 3 Apr 2021 at 17:30, Benjamin Eberlei wrote:
> The problem is that "void" is already not perfect, since the callside
> doesn't care about "return null" with no return type vs "return" + void
> return type.
>
> If we had "nothing" and "null" instead of "void", and we'd say like PHP
> works
On 03.04.21 18:30, Benjamin Eberlei wrote:
if (is_string($value) && is_int($value)) {
// inside here $value is_type == "never"
}
The naming "never" here makes no sense, because from a theoretical
perspective reasoning about the type of $value it is nothing and only the
block of code is "neve
> On Apr 2, 2021, at 5:49 PM, Larry Garfield wrote:
>
> On Fri, Apr 2, 2021, at 4:56 PM, Kamil Tekiela wrote:
>> Hi Go Kudo,
>>
>> First, let me say that I believe we need such implementation in PHP and I
>> would like to see object scoped RNG as part of the standard. However, I
>> have voted
On Sat, Apr 3, 2021 at 5:30 PM Benjamin Eberlei wrote:
>
>
> On Fri, Apr 2, 2021 at 3:14 AM Aaron Piotrowski wrote:
>
>>
>> > On Apr 1, 2021, at 2:03 PM, Levi Morrison via internals <
>> internals@lists.php.net> wrote:
>> >
>> > I do not care which name is chosen, but if we are going to have thi
On 03/04/2021 16:30, Benjamin Eberlei wrote:
But I again get to the point of the problem with this RFC due to naming.
"never" is actually combining "nothing" type with "noreturn" flag, so for
me the most consistent way would have been "public noreturn function foo():
nothing"
I'm not sure how
On Fri, Apr 2, 2021 at 3:14 AM Aaron Piotrowski wrote:
>
> > On Apr 1, 2021, at 2:03 PM, Levi Morrison via internals <
> internals@lists.php.net> wrote:
> >
> > I do not care which name is chosen, but if we are going to have this
> > sort of thing in the language, it ought to be a bottom type, no
On Tue, 23 Mar 2021 at 19:45, Matthew Brown
wrote:
> On Tue, 23 Mar 2021 at 05:32, G. P. B. wrote:
>
>> I'm calling this proposal pure intersection types as there would be no
>> possibility of mixing intersection and union types, I'm leaving this as a
>> future scope.
>>
>
> Does this miss an op
12 matches
Mail list logo
