On Sun, Aug 11, 2019 at 8:24 AM Nikita Popov wrote:
> After thinking about this a bit, this is going to be pretty hard to
> implement. Currently return type checks are performed using a separate
> opcode, which means that we need to know the return type at compile-time.
> At the point where inher
Le dim. 11 août 2019 à 15:24, Nikita Popov a écrit :
> On Sun, Aug 11, 2019 at 3:01 PM Sara Golemon wrote:
>
> > On Sun, Aug 11, 2019 at 7:51 AM Nikita Popov
> wrote:
> >
> >> On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon wrote:
> >> > P.S. - Perhaps a way to the middle might be to introduce im
On Sun, Aug 11, 2019 at 3:01 PM Sara Golemon wrote:
> On Sun, Aug 11, 2019 at 7:51 AM Nikita Popov wrote:
>
>> On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon wrote:
>> > P.S. - Perhaps a way to the middle might be to introduce implicit return
>> > type hints. If a child method is implemented wit
On Sun, Aug 11, 2019 at 7:51 AM Nikita Popov wrote:
> On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon wrote:
> > P.S. - Perhaps a way to the middle might be to introduce implicit return
> > type hints. If a child method is implemented with no return type
> specified
> > on a parent method which ha
The `strict_types` directive is limited to applying strict type checking,
throwing a TypeError instead of doing implicit type casting.
The strict operators RFC is trying to do the same. Unfortunately there are a
view of cases where this isn't easily possible and the statement will have a
differ
On Sun, Aug 11, 2019 at 2:37 PM Sara Golemon wrote:
> On Sun, Aug 11, 2019 at 3:44 AM Nikita Popov wrote:
>
>> What do you think about this? As we are currently annotating everything
>> with types, and we're at a major version, this would be the ideal time to
>> make this change. But there's cer
On Sun, Aug 11, 2019 at 3:44 AM Nikita Popov wrote:
> What do you think about this? As we are currently annotating everything
> with types, and we're at a major version, this would be the ideal time to
> make this change. But there's certainly a BC break here. (And, for the
> record, this is not
On Sat, Aug 10, 2019 at 6:21 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> 1- How would you envision a shared runtime between PHP and P++, in the
> case that this new evolved solution decides to support objects as keys
> in array structure? This fundamentally changes internals
On Sat, Aug 10, 2019 at 12:37 PM Andrea Faulds wrote:
> Hi Zeev,
>
> As the person who initially proposed and implemented strict_types, I
> think this is heading in the wrong direction. Perhaps that directive was
> a mistake, if it will lead to so many attempts inspired by it to
> fragment the la
Hi internals,
Something that came up in the arginfo thread: We can now add type
annotations for everything, apart from return types on methods of non-final
classes.
The reason is that adding these return types would require inheriting
classes to specify them as well. The same problem does not exi
+1
On Sun, 11 Aug 2019, 07:32 Andi Gutmans, wrote:
> I must admit that the first time I read Zeev’s email I got anxious... but
> it is frustrating that PHP has a WAY better runtime than Python and most
> other dynamic languages yet is falling out of fashion. It’s strange given
> how much better
11 matches
Mail list logo
