On 29 October 2015 at 02:57, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> I wonder what would be necessary to make this patch possible, if there's
> any interest to move this forward and potentially target it for 7.1
> release.
>
> I'm still interested in this, and willing to he
Hi,
The sixth release candidate for 7.0.0 was just released and can be
downloaded from:
https://downloads.php.net/~ab/
The Windows binaries are available at
http://windows.php.net/qa/
This release contains fixes for 10 reported bugs and marks the end of the
pre-release circle.
Please
Hi Internals,
Stanislav Malyshev wrote:
> every PHP function actually returns
> something (at least null). So this type would not actually be right and
> would not reflect what actually is happening.
Well obviously we would need to have a followup RFC to make void
functions not have a usable retu
On 29 October 2015 at 06:24, Marcio Almada wrote:
> Welcome back, Andrea! It's great to see you contributing here again :)
+1. :)
> 1) functions declared with "void" return type will still return
> "null", so "void" is a big fat lie for PHP while "null" is currently
> accurate.
I voted -1 for t
Like I said in a previous post, there is no need to forbid using a void
function return value.
Throwing an E_NOTICE would be sufficient to inform the developer he's doing
something weird (using the return value from a function that, by
definition, shouldn't have any return value) without breaking
Hi!
> type (or pseudo-type) to do this. We should add null as a return type
> rather than void as null:
I don't think we should do either. The whole story bases on the premise
that it is very important to avoid functions that accidentally return
non-null value. I do not think this premise is vali
On 29 October 2015 at 12:52, Stanislav Malyshev wrote:
> I don't think we should do either. The whole story bases on the premise
> that it is very important to avoid functions that accidentally return
> non-null value.
I don't think we should do either. The whole story bases on the premise
that i
On 29 October 2015 at 12:48, Pedro Cordeiro wrote:
> Like I said in a previous post, there is no need to forbid using a void
> function return value.
>
> Throwing an E_NOTICE would be sufficient to inform the developer he's doing
> something weird
To me, that is not really different from forbiddi
Pedro, your email client snipped off the internals CC
On 29 October 2015 at 13:11, Pedro Cordeiro wrote:
> If that callback is actually a void function, then using its return value IS
> an error. The same way using a variable you're not sure exists, using a
> return value that you don't know is t
Dan,
On Thu, Oct 29, 2015 at 9:22 AM, Dan Ackroyd wrote:
> Pedro, your email client snipped off the internals CC
>
> On 29 October 2015 at 13:11, Pedro Cordeiro wrote:
>> If that callback is actually a void function, then using its return value IS
>> an error. The same way using a variable you'r
Shouldn't gold wait for fixes on critical and reproducible bugs? Like
https://bugs.php.net/bug.php?id=70805 which is currently blocking
Drupal 8 from supporting PHP 7.0...
On Thu, Oct 29, 2015 at 8:15 AM, wrote:
> Hi,
>
> The sixth release candidate for 7.0.0 was just released and can be
> downl
I am confident that critical bugs will be resolved before release. And if
I am not mistaken, Drupal themselves found a fix.
However, it should go without saying that the November 12 deadline could be
pushed back if necessary.
On Thu, Oct 29, 2015 at 9:49 AM, Anthony Ferrara
wrote:
> Shouldn't
Johannes Schlüter wrote on 28/10/2015 22:56:
On Wed, 2015-10-28 at 16:45 +, Rowan Collins wrote:
On the downside, it's worth noting that while PHP destructors are
technically deterministic, the language can actually prevent them
running on scope exit, because Exceptions hold references to ev
Results for project PHP master, build date 2015-10-29 11:21:12+02:00
commit: f596c8a3e1b4fca155210c28e6f7789d18c5a6c4
revision date: 2015-10-29 15:02:00+08:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
mem
We found a workaround. We have to flush and disable the garbage collection
before the affected code. It is definitely not fixed.
On Thu, Oct 29, 2015 at 9:24 AM Adam Howard wrote:
> I am confident that critical bugs will be resolved before release. And if
> I am not mistaken, Drupal themselves
Hi!
> The use case is that it allows better static analysis
Any analyzer worth its bytes would know whether the function returns
non-null values (as opposed to whether you declared it to return it, the
former being much more useful). However, more important point that I
think introducing features
Hi,
Levi Morrison wrote:
On Wed, Oct 28, 2015 at 8:17 PM, François Laupretre wrote:
Hi Andrea,
Le 29/10/2015 01:08, Andrea Faulds a écrit :
The vote can be found here:
https://wiki.php.net/rfc/void_return_type#vote
Just voted +1 as, unlike some :), I like the idea of distinguishing voi
Hi Stas,
Stanislav Malyshev wrote:
Hi!
type (or pseudo-type) to do this. We should add null as a return type
rather than void as null:
I don't think we should do either. The whole story bases on the premise
that it is very important to avoid functions that accidentally return
non-null value.
Hi Guilherme,
guilhermebla...@gmail.com wrote:
Currently, there's no way to determine at runtime what is the scope of the
execution. This means you can't resolve if the current instruction is
happening on a top-level scope, in a class definition, namespace, function
or method.
Together with th
Hi Andrea,
I'm very happy to see you back! You're a great contributor to PHP... =)
Sorry, I may have written in a bad form, but here is the context...
Looking at this phpt file
https://github.com/guilhermeblanco/php-src/blob/class-modifiers/Zend/tests/visibility_modifiers/namespaced_private_class
Hi!
> There is a quite important use-case I've been informed of (alas I cannot
> recall who by), and it was one of the things that motivated me to revive
> the RFC. For interfaces, it's important to be strict in your
> definitions, so you don't end up with implementation-defined behaviour
> that p
Hi again,
guilhermebla...@gmail.com wrote:
I'm very happy to see you back! You're a great contributor to PHP... =)
Oh, er, thank you.
Sorry, I may have written in a bad form, but here is the context...
I think I might have just been too hasty to guess what you wanted it for.
Looking at t
Hi,
Stanislav Malyshev wrote:
Hi!
There is a quite important use-case I've been informed of (alas I cannot
recall who by), and it was one of the things that motivated me to revive
the RFC. For interfaces, it's important to be strict in your
definitions, so you don't end up with implementation-
Hi!
> Well yes, but the interface description currently says that it'll return
> a value of some unspecified type. That's what omitting the return type
> declaration does.
No, it doesn't do that. It doesn't do anything - it just provides no
information. If you rely on it to return something, then
Hi,
2015-10-29 17:43 GMT-03:00 Stanislav Malyshev :
> Hi!
>
>> Well yes, but the interface description currently says that it'll return
>> a value of some unspecified type. That's what omitting the return type
>> declaration does.
>
> No, it doesn't do that. It doesn't do anything - it just provid
Hi!
> "void" or "null" as return type would give a 100% guarantee that every
> possible
> implementation of a given interface won't return any random value. Then it
> would
> make no difference if the returned value is being used or not, as it
> would always
> be null.
>
> So, it obviously solv
On 10/29/2015 08:55 PM, Stanislav Malyshev wrote:
> Hi!
>
>> "void" or "null" as return type would give a 100% guarantee that every
>> possible
>> implementation of a given interface won't return any random value. Then it
>> would
>> make no difference if the returned value is being used or not,
27 matches
Mail list logo
