Re: [PHP-DEV] PHP 7.1 roadmap

[Joe Watkins]

Morning internals,

If Davey wants another person, that could be me.

Cheers
Joe
On 24 Apr 2016 01:29, "Davey Shafik"  wrote:

> On Sat, Apr 23, 2016 at 11:06 AM, Anatol Belski 
> wrote:
>
> > Hi Davey,
> >
> > > -Original Message-
> > > From: m...@daveyshafik.com [mailto:m...@daveyshafik.com] On Behalf Of
> Davey
> > > Shafik
> > > Sent: Friday, April 22, 2016 5:03 AM
> > > To: Julien Pauli 
> > > Cc: Scott Arciszewski ; Anatol Belski  >;
> > > PHP internals ; Ferenc Kovacs <
> tyr...@gmail.com
> > >;
> > > Stanislav Malyshev 
> > > Subject: Re: [PHP-DEV] PHP 7.1 roadmap
> > >
> > > I'd interested in co-RMing 7.1 if someone else wants to step up also?
> > >
> > > - Davey
> > >
> > Thanks for the response. So, how would you see being the master RM for
> > 7.1? I'd introduce you to the basics and would support in the pre-phase,
> so
> > then you'd be fit to do things independently later on. If later there's
> yet
> > one more volunteer, they can join you right at the moment. Otherwise you
> > could count on me with some on demand help, ofc.
> >
> > Thanks.
> >
> > Anatol
>
>
> Anatol,
>
> I'm honestly not 100% sure what all is involved, is this documented
> somewhere?
>
> I'm a bit worried that my lack of C mastery will be an issue, but if that's
> not a problem, then I'd be glad to move forward as you say above.
>
> - Davey
>

Re: [PHP-DEV][RFC] Callable Types

[Mathieu Rochette]

On 04/23/2016 08:34 PM, Marcio Almada wrote:
> hi!
>
> From: Mathieu Rochette 
>> Date: 2016-04-23 12:44 GMT-04:00
>> Subject: Re: [PHP-DEV][RFC] Callable Types
>>
>>
>> On 04/22/2016 06:12 AM, Marcio Almada wrote:
>>
>> Hello everyone,
>>
>> We just completed the draft for the "Callable Types" RFC. This RFC has been
>> recently mentioned during other type related threads on this mailing list,
>> so it feels to be the right time to put the proposal in context:
>>
>> The proposal is at https://wiki.php.net/rfc/callable-types
>>
>> It looks very nice overall :) and would be, imho, a great addition to PHP
>>
>>
>> I have a few comments, first about the optional arguments, the example in
>> the rfc says :
>>> // That means that foo() could call $cb and pass anything as a first
>> argument and if it would be something that is not an instance of A the call
>> would fail.
>> I don't get why foo would be declared as
>>
>> function foo(callable() $cb) { }
>>
>> instead of
>>
>> function foo(callable($any) $cb) { }
>>
>> if foo intends to call $cb with an argument.
>>
>>
>> what about optional arguments, eg:
>>
>> class Foo
>> {
>>   private $logger;
>>   public __construct(Logger $logger = null) {$this->logger = $logger;}
>>   public doSomething(callable(int $done, int $remaining, Logger = null)
>> $progressCb) {
>> // ...
>> for($i = 0; $i < $n; $i++) {
>>   // ...
>>   $progressCb($i, $n - $i, $this->logger);
>> }
>>   }
>> }
>>
>> should that be supported ?
>>
>>
> Currently you can nullify or skip the Logger argument upon implementation
> of the callable. Rendering your example:
>
> https://3v4l.org/qb5QR/rfc#tabs
>
> Admittedly, the expectation for default values to work seems legit and we
> are currently discussing whether to support
> default values on callable types signatures or not (inclined to do not
> support). But honestly I haven't seen a legit use
> case when we already have the ability to satisfy the callback with a
> smaller type. Perhaps you may have one use case
> where a default value would be indispensable?
I wouldn't say it's indispensable. it's just that in the previous
example, the class Foo cannot say that the #rd argument of the callable
is either a Logger or null.
that means that giving function(int $done, int
$remaining){var_dump($remaining);} works but function(int $done, int
$remaining, Logger $logger){$logger->debug($remaining);} does
not even though it is compatible with the callable signature. and
afaikt, I cannot make a signature without a default null value or one of
the rfc about union types or nullable types

>
>
>> and last one, will instanceof supports this new syntax?
>>
>>
> Yes, please expect to see this on the next minor version of the RFC :)
great !


I've seen someone mentioning variadics so I made a few small tests, I
think those two should work (they currently don't):

https://3v4l.org/eZgR9/rfc#rfc-callable_typehint
https://3v4l.org/N7i0u/rfc#rfc-callable_typehint

and this one should not:

https://3v4l.org/fcRlT/rfc#rfc-callable_typehint


>
>
>
>> thank you
>>
>> The W.I.P patch is available for testing through http://3v4l.org under the
>> RFC tab.
>>
>> We count with your detailed feedback and insights. Let's have a nice,
>> respectful and
>> constructive conversation about the RFC and work on possible improvements!
>>
>> Thanks
>> Nikita Nefedov
>> Márcio Almada
>>
>>
>> --
>> Mathieu Rochette
>>
>>
> Cheers.
>

-- 
Mathieu Rochette

[PHP-DEV] Re: ext/curl update

[Pierrick Charron]

Hi Davey,

Thanks for your answer. I still have small projects on my pipeline that I
want to finish but I'll start looking at libnghttp2 and if I get some time
I'll recontact you to maybe help you on remaining tasks :-) Do you have
specifics stuffs that you would like me to look at ?

About the patch if there is no objection i'll commit it to the 7.1 branch
soon.

Pierrick

On 23 April 2016 at 20:24, Davey Shafik  wrote:

> Hi Pierrick,
>
> This should be in master for 7.1, alongside my RFC'ed patch for server
> push support.
>
> You emailed me directly about the aforementioned patch so I'll just
> respond here as it's relevant:
>
> The patch should hit in 7.1 but it has been requested that tests be added
> — and we can't add tests with a server push supporting HTTP/2 server
> against which to push.
>
> I'm working with Pierre Joye (CC'ed) to try and update the cli-server to
> use libnghttp2 to turn it into a fully fledged HTTP/2 compliant server with
> support for server push and things like multiplexing (see:
> http://wiki.php.net/rfc/cli_server_http2). Curl also uses libnghttp2 for
> it's HTTP/2 support.
>
> I hope to eventually (7.2+) use libnghttp2 to add an ext/nghttp2 HTTP
> client and update the HTTP streams layer to support HTTP/2 also.
>
> I'd welcome your collaboration on any of this.
>
> - Davey
>
> On Sat, Apr 23, 2016 at 12:30 PM, Pierrick Charron 
> wrote:
>
>> Hi internals,
>>
>> I took some time to add some easy to implement new "features" that were
>> implemented in libcurl but missing in ext/curl. Most of them are just
>> exposing a new constant in ext/curl and dispatched in the curl_setopt
>> function. I created a branch over master but the patch is applicable
>> without conflict the 7.0 branch.
>>
>> https://github.com/php/php-src/compare/master...adoy:curl-update
>>
>> I was wondering since it's not a big patch and it only introduce new
>> constants :
>>
>> - Should I commit this patch to 7.0 and master or only master
>> - Should I do a RFC to include this patch ?
>>
>> Thanks for your feedback
>> Pierrick
>>
>>
>>
>>
>>
>>
>>
>

Re: [PHP-DEV] PHP 7.1 roadmap

[Davey Shafik]

On Sat, Apr 23, 2016 at 11:06 AM, Anatol Belski 
wrote:

> Hi Davey,
>
> > -Original Message-
> > From: m...@daveyshafik.com [mailto:m...@daveyshafik.com] On Behalf Of Davey
> > Shafik
> > Sent: Friday, April 22, 2016 5:03 AM
> > To: Julien Pauli 
> > Cc: Scott Arciszewski ; Anatol Belski ;
> > PHP internals ; Ferenc Kovacs  >;
> > Stanislav Malyshev 
> > Subject: Re: [PHP-DEV] PHP 7.1 roadmap
> >
> > I'd interested in co-RMing 7.1 if someone else wants to step up also?
> >
> > - Davey
> >
> Thanks for the response. So, how would you see being the master RM for
> 7.1? I'd introduce you to the basics and would support in the pre-phase, so
> then you'd be fit to do things independently later on. If later there's yet
> one more volunteer, they can join you right at the moment. Otherwise you
> could count on me with some on demand help, ofc.
>
> Thanks.
>
> Anatol


Anatol,

I'm honestly not 100% sure what all is involved, is this documented
somewhere?

I'm a bit worried that my lack of C mastery will be an issue, but if that's
not a problem, then I'd be glad to move forward as you say above.

- Davey

[PHP-DEV] Re: ext/curl update

[Davey Shafik]

Hi Pierrick,

This should be in master for 7.1, alongside my RFC'ed patch for server push
support.

You emailed me directly about the aforementioned patch so I'll just respond
here as it's relevant:

The patch should hit in 7.1 but it has been requested that tests be added —
and we can't add tests with a server push supporting HTTP/2 server against
which to push.

I'm working with Pierre Joye (CC'ed) to try and update the cli-server to
use libnghttp2 to turn it into a fully fledged HTTP/2 compliant server with
support for server push and things like multiplexing (see:
http://wiki.php.net/rfc/cli_server_http2). Curl also uses libnghttp2 for
it's HTTP/2 support.

I hope to eventually (7.2+) use libnghttp2 to add an ext/nghttp2 HTTP
client and update the HTTP streams layer to support HTTP/2 also.

I'd welcome your collaboration on any of this.

- Davey

On Sat, Apr 23, 2016 at 12:30 PM, Pierrick Charron 
wrote:

> Hi internals,
>
> I took some time to add some easy to implement new "features" that were
> implemented in libcurl but missing in ext/curl. Most of them are just
> exposing a new constant in ext/curl and dispatched in the curl_setopt
> function. I created a branch over master but the patch is applicable
> without conflict the 7.0 branch.
>
> https://github.com/php/php-src/compare/master...adoy:curl-update
>
> I was wondering since it's not a big patch and it only introduce new
> constants :
>
> - Should I commit this patch to 7.0 and master or only master
> - Should I do a RFC to include this patch ?
>
> Thanks for your feedback
> Pierrick
>
>
>
>
>
>
>

Re: [PHP-DEV] [RFC] PHP Attributes

[Benoit Schildknecht]

If I was a popular framework creator, this wouldn't stop me. I would  
release two packages : one for 7.0, another one for 7.1. And the 7.0 one  
would be the 7.1 one that has been processed through a script to remove  
any <<>> syntax, or to transform it (if pre/post attributes instructions  
were to be implemented in the core).


Regards,
Ben.

Le Sun, 24 Apr 2016 01:09:08 +0200, "Thomas Bley"  a  
écrit:


The <<>> syntax comes with the problem that previous versions cannot  
ignore it on parsing.
So poeple write new frameworks for 7.0 which cannot be parsed in 5.x,  
then they write new frameworks for 7.1 which cannot be parsed with 7.0  
and 5.x and so on.
For companies staying on Linux distributions with long term support on  
7.0, this is rather a nightmare for both users and framework maintainers.
When choosing <<>> or any other non-backward compatible syntax for 7.1,  
there should be a patch for 7.0 to ignore the new syntax without parse  
errors.


Regards
Thomas

Fleshgrinder wrote on 23.04.2016 17:29:


+1 for the basic idea, however, I have various remarks.

The RFC text is hard to read and contains many grammatical mistakes. How
could one help you here?

I think that the Hack name attributes is unintelligible and annotations
would be much clearer to any audience. Simply because the name is very
well known.

I do not see the need for multi-annotation nor multi-value support. It
just creates multiple ways to achieve the exact same thing for no good
reason.

I do not like the <<>> syntax. It requires many key strokes, is hard to
read, and looks ugly. Why not simply @ and be done with it. I am not so
sure about the bracket requirement, is it somehow required for the
parsing? Otherwise I would leave it off. I guess it might be hard to
find the end of an annotation but have you considered to use the
semicolon for that? Would align nicely with existing PHP syntax. The
following would be the ABNF for my proposal:

ANNOTATION= "@" NAME [ " " VALUE ]
NAME  = STRING
VALUE = QUOTED-STRING / PHP-CONSTANT / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION= PHP-CODE ";"

A semicolon would only be required if it is not a single quoted string
(see following example) or constant. A question that I see unanswered is
how embedding of variables in quoted strings should be dealt with. I see
no need for this but people might assume it is supported because PHP
supports it everywhere else.

"
class A {}

<")>>
class B {}

?>

Requiring PHP code to be terminated with a semicolon should also ensure
that people do not start to write fully-fledged programs in annotations.
Since that is not what they are intended for. An alternative approach I
see here would be to go for the brackets but then again only for PHP  
code:


EXPRESSION = "(" PHP-CODE ")"

Then again, it looks similar to a function call and this is imho not
good. Unless of course new annotations can be defined as special
functions directly in userland, e.g. with an `annotation function`
and/or `annotation class`. However, this would require more thought.

Another question that is unanswered for me is: how to go about adding
annotations to a complete file as is currently possible with PhpDoc and
its file-level doc block:

'
@copyright '2016 Richard Fussenegger'
@license 'MIT'

declare(strict_types=1);

namespace Fleshgrinder\PhpInternals;

@description 'True annotation support could be a very good thing.'
@invariant $this->balance >= self::MIN_BALANCE;
class Account {

 private const int MIN_BALANCE = 0;

 private int $balance;

 private Person $owner;

 @require $sum >= 0;
 @ensure $this->balance === (old::$balance + $sum);
 public function deposit(int $sum): void {
   $this->balance += $sum;
 }

 @require $sum >= 0;
 @require $sum <= $this->balance - self::MIN_BALANCE;
 @ensure $this->balance === (old::$balance - $sum);
 public function withdraw(int $sum): void {
   $this->balance -= $sum;
 }

 @deprecated 'for various reasons'
 public function setOwner(Person $wner): void {
   $this->owner = $owner;
 }

}

@inheritDoc
class OverdraftAccount extends Account {

 private const int MIN_BALANCE = -1000;

}

?>

We also need to make sure to add something regarding coding standards
for annotation names. I would propose to go for camelCase (same as for
method names) since this is what PhpDoc used to use for many years now.

We also need to define how people can avoid to collide with internal
annotations. The typical double-underscore prefix approach that we have
for magic methods creates a lot of visual clutter and looks weird if
spread among all kinds of places. A namespace approach as we have it
already for userland code could help here.

 'user',
 'unique_constraints' => [
   'name' => 'user_unique',
   'columns' => [ 'username' ],
 ],
 'indexes' => [
   'name' => 'user_idx',
   'clumns' => [ 'email' ],
 ],
 'schema' => 'schema_name',
];
class User {}

?>

--

Re: [PHP-DEV] [RFC] PHP Attributes

[Yasuo Ohgaki]

Hi Dimitry,

On Fri, Apr 22, 2016 at 6:13 AM, Dmitry Stogov  wrote:
> I would like to present an RFC proposing support for native annotation.
>
> The naming, syntax and behavior are mostly influenced by HHVM Hack, but not 
> exactly the same.
>
> The most interesting difference is an ability to use arbitrary PHP 
> expressions as attribute values.
>
> These expressions are not evaluated, but stored as Abstract Syntax Trees, and 
> later may be accessed (node by node) in PHP extensions, preprocessors and PHP 
> scripts their selves. I think this ability may be useful for "Design By 
> Contract", other formal verification systems, Aspect Oriented Programming, etc
>
>
> https://wiki.php.net/rfc/attributes
>
>
> Note that this approach is going to be native, in contrast to doc-comment 
> approach that uses not well defined syntax, and even not parsed by PHP itself.
>
>
> Additional ideas, endorsement and criticism are welcome.

Nice RFC!
Attributes are always evaluated, right? i.e. No INI switch nor declare
to control behavior.
Just making sure.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ext/curl update

[Pierrick Charron]

Hi internals,

I took some time to add some easy to implement new "features" that were
implemented in libcurl but missing in ext/curl. Most of them are just
exposing a new constant in ext/curl and dispatched in the curl_setopt
function. I created a branch over master but the patch is applicable
without conflict the 7.0 branch.

https://github.com/php/php-src/compare/master...adoy:curl-update

I was wondering since it's not a big patch and it only introduce new
constants :

- Should I commit this patch to 7.0 and master or only master
- Should I do a RFC to include this patch ?

Thanks for your feedback
Pierrick

Re: [PHP-DEV][RFC] Callable Types

[Marcio Almada]

hi!

From: Mathieu Rochette 
> Date: 2016-04-23 12:44 GMT-04:00
> Subject: Re: [PHP-DEV][RFC] Callable Types
>
>
> On 04/22/2016 06:12 AM, Marcio Almada wrote:
>
> Hello everyone,
>
> We just completed the draft for the "Callable Types" RFC. This RFC has been
> recently mentioned during other type related threads on this mailing list,
> so it feels to be the right time to put the proposal in context:
>
> The proposal is at https://wiki.php.net/rfc/callable-types
>
> It looks very nice overall :) and would be, imho, a great addition to PHP
>
>
> I have a few comments, first about the optional arguments, the example in
> the rfc says :
> > // That means that foo() could call $cb and pass anything as a first
> argument and if it would be something that is not an instance of A the call
> would fail.
> I don't get why foo would be declared as
>
> function foo(callable() $cb) { }
>
> instead of
>
> function foo(callable($any) $cb) { }
>
> if foo intends to call $cb with an argument.
>
>
> what about optional arguments, eg:
>
> class Foo
> {
>   private $logger;
>   public __construct(Logger $logger = null) {$this->logger = $logger;}
>   public doSomething(callable(int $done, int $remaining, Logger = null)
> $progressCb) {
> // ...
> for($i = 0; $i < $n; $i++) {
>   // ...
>   $progressCb($i, $n - $i, $this->logger);
> }
>   }
> }
>
> should that be supported ?
>
>
Currently you can nullify or skip the Logger argument upon implementation
of the callable. Rendering your example:

https://3v4l.org/qb5QR/rfc#tabs

Admittedly, the expectation for default values to work seems legit and we
are currently discussing whether to support
default values on callable types signatures or not (inclined to do not
support). But honestly I haven't seen a legit use
case when we already have the ability to satisfy the callback with a
smaller type. Perhaps you may have one use case
where a default value would be indispensable?


>
> and last one, will instanceof supports this new syntax?
>
>

Yes, please expect to see this on the next minor version of the RFC :)



>
> thank you
>
> The W.I.P patch is available for testing through http://3v4l.org under the
> RFC tab.
>
> We count with your detailed feedback and insights. Let's have a nice,
> respectful and
> constructive conversation about the RFC and work on possible improvements!
>
> Thanks
> Nikita Nefedov
> Márcio Almada
>
>
> --
> Mathieu Rochette
>
>
Cheers.

[PHP-DEV][RFC] Callable Types

[Marcio Almada]

Redirecting this to the list as this message was sent privately probably by
accident :)

-- Forwarded message --
From: Mathieu Rochette 
Date: 2016-04-23 12:44 GMT-04:00
Subject: Re: [PHP-DEV][RFC] Callable Types
To: Marcio Almada 


On 04/22/2016 06:12 AM, Marcio Almada wrote:

Hello everyone,

We just completed the draft for the "Callable Types" RFC. This RFC has been
recently mentioned during other type related threads on this mailing list,
so it feels to be the right time to put the proposal in context:

The proposal is at https://wiki.php.net/rfc/callable-types

It looks very nice overall :) and would be, imho, a great addition to PHP


I have a few comments, first about the optional arguments, the example in
the rfc says :
> // That means that foo() could call $cb and pass anything as a first
argument and if it would be something that is not an instance of A the call
would fail.
I don't get why foo would be declared as

function foo(callable() $cb) { }

instead of

function foo(callable($any) $cb) { }

if foo intends to call $cb with an argument.


what about optional arguments, eg:

class Foo
{
  private $logger;
  public __construct(Logger $logger = null) {$this->logger = $logger;}
  public doSomething(callable(int $done, int $remaining, Logger = null)
$progressCb) {
// ...
for($i = 0; $i < $n; $i++) {
  // ...
  $progressCb($i, $n - $i, $this->logger);
}
  }
}

should that be supported ?


and last one, will instanceof supports this new syntax?



thank you

The W.I.P patch is available for testing through http://3v4l.org under the
RFC tab.

We count with your detailed feedback and insights. Let's have a nice,
respectful and
constructive conversation about the RFC and work on possible improvements!

Thanks
Nikita Nefedov
Márcio Almada



-- 
Mathieu Rochette

RE: [PHP-DEV] PHP 7.1 roadmap

[Anatol Belski]

Hi Davey,

> -Original Message-
> From: m...@daveyshafik.com [mailto:m...@daveyshafik.com] On Behalf Of Davey
> Shafik
> Sent: Friday, April 22, 2016 5:03 AM
> To: Julien Pauli 
> Cc: Scott Arciszewski ; Anatol Belski ;
> PHP internals ; Ferenc Kovacs ;
> Stanislav Malyshev 
> Subject: Re: [PHP-DEV] PHP 7.1 roadmap
> 
> I'd interested in co-RMing 7.1 if someone else wants to step up also?
> 
> - Davey
> 
Thanks for the response. So, how would you see being the master RM for 7.1? I'd 
introduce you to the basics and would support in the pre-phase, so then you'd 
be fit to do things independently later on. If later there's yet one more 
volunteer, they can join you right at the moment. Otherwise you could count on 
me with some on demand help, ofc.  

Thanks.

Anatol

> On Thu, Apr 21, 2016 at 2:47 AM, Julien Pauli   > wrote:
> 
> 
>   On Tue, Apr 12, 2016 at 10:20 PM, Scott Arciszewski
>  > wrote:
>   > On Tue, Apr 12, 2016 at 2:29 PM, Anatol Belski   > wrote:
>   >>
>   >> Hi,
>   >>
>   >> Time goes by fast - no sooner 7.0 was unleashed on the world than
> 7.1
>   >> bangs
>   >> at the door.  I would like to bring a couple of points regarding 
> this.
>   >>
>   >> There is enough time yet, but it would make full sense all the RFC
> authors
>   >> targeting 7.1 to finalize the work and get the RFC voted. Or the 
> RFCs,
>   >> that
>   >> have not been discussed yet - still some time is there to go through
> the
>   >> full RFC process and get them ready for 7.1. It is anyway the right
> moment
>   >> to intensify the discussions and work on 7.1 features and patches.
>   >>
>   >> It looks also like the right time to elect the 7.1 RMs. Please 
> everyone
>   >> interested to run for 7.1 RMs announce your candidacy to this
> thread. I
>   >> would suggest to start the poll on this two weeks after this message,
> with
>   >> the two weeks vote period.
>   >>
>   >> The prerelease cycle start could then happen already in June (or 
> July,
>   >> depends whether one wants to wait till 5.5 EOL). Anyway, having the
> new
>   >> RMs
>   >> team we can start to plan and proceed with the 7.1 prerelease cycle.
>   >>
>   >> Thanks
>   >>
>   >> Anatol
>   >>
>   >>
>   >> --
>   >> PHP Internals - PHP Runtime Development Mailing List
>   >> To unsubscribe, visit: http://www.php.net/unsub.php
>   >>
>   >
>   > Yikes, time really flies.
>   >
>   > The new ext/sodium is out, so I suppose it's high time to get that RFC
> ready
>   > to be voted on.
> 
> 
> 
>   Time runs :-)
> 
>   Anyone for RMing 7.1 ?
>   We obviously need someone to volunteer :-p
> 
> 
>   Julien.Pauli
> 
> 
>   --
>   PHP Internals - PHP Runtime Development Mailing List
>   To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC] Callable Types

[Jesse Schalken]

I see. So it's the combination of not erroring when more parameters are
passed than a function accepts, and permitting methods to add extra
optional parameters that is wrong. So without the former being
fix/deprecated, the correct thing to do is to disallow extra optional
params. Makes sense.

Are there any valid use cases for passing extra parameters to a function
any more, now that there is the varargs syntax to replace func_get_args()?
If not, maybe it could be deprecated by this RFC.

Regarding references, by-ref invariance for parameters makes sense, and is
what method compatibility does. According to method compatibility and
call-time behaviour however, return by-ref is effectively a subtype of
return by-value:

function _ref() {
$f = 0;
return $f;
}

function returns_val() {
return 1;
}

$v1 = returns_ref(); // ok
$v2 =& returns_ref(); // ok
$v3 = returns_val(); // ok
$v4 =& returns_val(); // Notice: Only variables should be assigned by
reference

interface Methods {
function ();
function returnsVal();
}

class ReturnRef implements Methods {
function () {} // ok
function () {} // ok
}

class ReturnVal implements Methods {
function returnsRef() {} // Fatal error: Declaration of
ReturnVal::returnsRef() must be compatible with & Methods::returnsRef()
function returnsVal() {} // ok
}


Otherwise it LGTM

cheers


On Sat, Apr 23, 2016 at 8:37 PM, Nikita Nefedov  wrote:

> On Sat, 23 Apr 2016 10:46:38 +0300, Jesse Schalken 
> wrote:
>
> This is great. The gaps in PHP's type annotations are slowly being filled.
>> :)
>>
>> Are the rules for compatibility between callables the same rules for
>> compatibility between methods in classes/interfaces? Because presently,
>> this is allowed:
>>
>> interface Test {
>> public function testMethod();
>> }
>>
>> function foo1(Test $x) { }
>>
>> foo1(new class implements Test {
>> public function testMethod(int $extraParam = 0) { }
>> });
>>
>>
>> but, according to the RFC, this would not be:
>>
>> function foo2(callable():void $x) { }
>>
>> foo2(function (int $extraParam = 0) { });
>>
>>
>> I don't see why they should be different.
>>
>> I also didn't see anything mentioning reference parameters/returns. I
>> assume it just follows the rules for method compatibility?
>>
>
> Hey Jesse,
>
> Thanks for reading the RFC.
>
> First and foremost - no, the rules for compatibility between callables
> and method implementations are different at least because our
> inheritance model currently doesn't support variance for every case:
>
> if you have
>
> class B extends A {}
>
> interface Foo {
> function foo(B $b);
> }
>
> then implementation of `foo()` can never have `foo(A $a)` signature,
> which is crucial for callables for some cases. Note that callables
> have runtime variance, where classes would have compile-time variance).
>
> So, in this way, callables have it right (it is desirable for classes
> to have variance as well, but currently it's not possible as there is
> a need for another compilation phase for verifying variance).
>
> What about your case of variance with extra optional parameter, it is
> actually not type safe with the current way of how PHP works (it's
> covered in the end of "Variance and Signature Validation" part).
> The problem lies in the notion that passing extra arguments to the
> function (the ones it doesn't even expect nor use) is considered
> valid and doesn't throw an error.
> So if you have a function that accepts optional argument of type B and
> you pass this function as a parameter of type `callable() $cb`, then
> it would be perfectly valid to call it as `$cb(new A);` because you
> assume that $cb is of type `callable()` and that means if you pass
> anything extra - it shouldn't Fatal. But in this case it would.
>
> While I agree that your use case is legit and ideally should be
> supported, I don't think it is safe to support it until PHP deprecates
> passing extra args to functions that don't expect them (which is very
> troublesome to implement due to BC).
>
> Anyway, changing this behavior of callable type later on wouldn't
> break BC so the gates will still be open.
>
> I've just added a part about references to the RFC (and found a
> bug in the implementation, thanks for that =)), I'll just copy
> and paste it here:
>
> Reference parameters are supported: no variance is applied to
> the fact whether parameter is referential or not.
>
> Example:
>
> function foo(callable(&$byref) $cb) { }
>
> foo(function (&$bar) { }); // valid
> foo(function ($bar) { }); // TypeError: Argument 1 passed to foo()
> must be callable of compliant signature: callable(&$byref), callable($bar)
> given
>
> function bar(callable($byval) $cb) { }
>
> bar(function (&$bar) { }); // TypeError: Argument 1 passed to bar()
> must be callable of compliant signature: callable($byval), callable(&$bar)
> given
>
> Functions returning a 

Re: [PHP-DEV] [RFC] Nullable Types

[Quim Calpe]

On Sat, Apr 23, 2016 at 6:58 PM, Levi Morrison  wrote:

> On Sat, Apr 23, 2016 at 10:40 AM, Quim Calpe  wrote:
> > Hi Richard,
> >
> > On Sat, Apr 23, 2016 at 2:30 PM, Fleshgrinder 
> wrote:
> >
> >> On 4/22/2016 11:42 AM, Quim Calpe wrote:
> >> > IMHO, the point of Optional types is the intention, if you get an
> >> > Option from a method, you have to deal with a None branch. Of
> course
> >> > you can just unwrap and go on, but it's a developer decision to do
> that,
> >> > not an oversight as using a Foo|null (or ?Foo) as an object directly.
> >> >
> >>
> >> IMOH, the point of ?T is the intention, if you get a null from a method,
> >> you have to deal with a null branch. Of course you can just ignore it
> >> and go on, but it's a developer decision to do that, not an oversight as
> >> using a Option as an object directly.
> >>
> >> Sorry, but this works in both directions. The problem is not null, the
> >> problem is that there is no system that warns you (e.g. a compiler)
> >> about the missing null check. I think that Ceylon solved this problem
> >> extremely nicely without the introduction of something special.
> >>
> >
> > Of course, this works in both directions, but I see a value in Option
> types:
> >
> > function getByEmail(string $email) : ?User {}
> > $user = getByEmail("f...@bar.com");
> > echo $user->getName();
> >
> > I neglect the nullable return but works at first , all fine...
> > .. a week later... "Warning: Call to a member function getName() on null"
> >
> > With Option type:
> > function getByEmail(string $email) : Option[User] {}
> > $user = getByEmail("f...@bar.com");
> > echo $user->getName();
> >
> > IDE could warn me and It crashes right away, an option type must be
> > unwrapped so I get the "intention" immediately :)
> >
> >
> >>
> >> function fn(): ?T {}
> >>
> >> $x = fn();
> >> if (is $x T) {}
> >> else {}
> >>
> >> Not doing as above is a compiler error in Ceylon. However, I already
> >> wrote multiple times that there are already statical code analysis tools
> >> available that can find exactly such things in your code. One just needs
> >> to use them.
> >>
> >
> > That's really nice
> >
> >>
> >> --
> >> Richard "Fleshgrinder" Fussenegger
> >>
> >>
> > Option types are nice, but I feel we are going a bit off-topic. Option
> > types work better with other niceties like for comprehensions, pattern
> > matching... And I don't see PHP going that route in the near future, and
> > probably It's not okay for PHP to go that route...
> >
> > Nullable return types is a better fit for PHP, null has been in the
> > language from the beginning, I agree here
>
> Option is no better than a union type with null[1]. If a language
> requires an option to be unwrapped then it can do the same with some
> type or null. This is what Swift does. These things are exactly
> equivalent.
>

My point was about the developer receiving an Optional type, being less
error-prone than a nullable type. Not a language advantage.


>
> However in PHP we do not have generics, which means a nullable type is
> actually better because we can express the type that participates with
> null. With an Option type we cannot.
>

Yes, I was talking generically here, Option Types without generics-like
behaviour are a lot less useful
Nullable return types is indeed a better fit for PHP as I said

  [1] At least with the behaviors here. If Option is a Traverable that
> returns 0 or 1 items then we can use that behavior to our advantage.
> Of course, we lose the ability to express the underlying option type.
>

Re: [PHP-DEV] [RFC] Nullable Types

[Levi Morrison]

On Sat, Apr 23, 2016 at 10:40 AM, Quim Calpe  wrote:
> Hi Richard,
>
> On Sat, Apr 23, 2016 at 2:30 PM, Fleshgrinder  wrote:
>
>> On 4/22/2016 11:42 AM, Quim Calpe wrote:
>> > IMHO, the point of Optional types is the intention, if you get an
>> > Option from a method, you have to deal with a None branch. Of course
>> > you can just unwrap and go on, but it's a developer decision to do that,
>> > not an oversight as using a Foo|null (or ?Foo) as an object directly.
>> >
>>
>> IMOH, the point of ?T is the intention, if you get a null from a method,
>> you have to deal with a null branch. Of course you can just ignore it
>> and go on, but it's a developer decision to do that, not an oversight as
>> using a Option as an object directly.
>>
>> Sorry, but this works in both directions. The problem is not null, the
>> problem is that there is no system that warns you (e.g. a compiler)
>> about the missing null check. I think that Ceylon solved this problem
>> extremely nicely without the introduction of something special.
>>
>
> Of course, this works in both directions, but I see a value in Option types:
>
> function getByEmail(string $email) : ?User {}
> $user = getByEmail("f...@bar.com");
> echo $user->getName();
>
> I neglect the nullable return but works at first , all fine...
> .. a week later... "Warning: Call to a member function getName() on null"
>
> With Option type:
> function getByEmail(string $email) : Option[User] {}
> $user = getByEmail("f...@bar.com");
> echo $user->getName();
>
> IDE could warn me and It crashes right away, an option type must be
> unwrapped so I get the "intention" immediately :)
>
>
>>
>> function fn(): ?T {}
>>
>> $x = fn();
>> if (is $x T) {}
>> else {}
>>
>> Not doing as above is a compiler error in Ceylon. However, I already
>> wrote multiple times that there are already statical code analysis tools
>> available that can find exactly such things in your code. One just needs
>> to use them.
>>
>
> That's really nice
>
>>
>> --
>> Richard "Fleshgrinder" Fussenegger
>>
>>
> Option types are nice, but I feel we are going a bit off-topic. Option
> types work better with other niceties like for comprehensions, pattern
> matching... And I don't see PHP going that route in the near future, and
> probably It's not okay for PHP to go that route...
>
> Nullable return types is a better fit for PHP, null has been in the
> language from the beginning, I agree here

Option is no better than a union type with null[1]. If a language
requires an option to be unwrapped then it can do the same with some
type or null. This is what Swift does. These things are exactly
equivalent.

However in PHP we do not have generics, which means a nullable type is
actually better because we can express the type that participates with
null. With an Option type we cannot.

  [1] At least with the behaviors here. If Option is a Traverable that
returns 0 or 1 items then we can use that behavior to our advantage.
Of course, we lose the ability to express the underlying option type.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Types

[Quim Calpe]

Hi Richard,

On Sat, Apr 23, 2016 at 2:30 PM, Fleshgrinder  wrote:

> On 4/22/2016 11:42 AM, Quim Calpe wrote:
> > IMHO, the point of Optional types is the intention, if you get an
> > Option from a method, you have to deal with a None branch. Of course
> > you can just unwrap and go on, but it's a developer decision to do that,
> > not an oversight as using a Foo|null (or ?Foo) as an object directly.
> >
>
> IMOH, the point of ?T is the intention, if you get a null from a method,
> you have to deal with a null branch. Of course you can just ignore it
> and go on, but it's a developer decision to do that, not an oversight as
> using a Option as an object directly.
>
> Sorry, but this works in both directions. The problem is not null, the
> problem is that there is no system that warns you (e.g. a compiler)
> about the missing null check. I think that Ceylon solved this problem
> extremely nicely without the introduction of something special.
>

Of course, this works in both directions, but I see a value in Option types:

function getByEmail(string $email) : ?User {}
$user = getByEmail("f...@bar.com");
echo $user->getName();

I neglect the nullable return but works at first , all fine...
.. a week later... "Warning: Call to a member function getName() on null"

With Option type:
function getByEmail(string $email) : Option[User] {}
$user = getByEmail("f...@bar.com");
echo $user->getName();

IDE could warn me and It crashes right away, an option type must be
unwrapped so I get the "intention" immediately :)


>
> function fn(): ?T {}
>
> $x = fn();
> if (is $x T) {}
> else {}
>
> Not doing as above is a compiler error in Ceylon. However, I already
> wrote multiple times that there are already statical code analysis tools
> available that can find exactly such things in your code. One just needs
> to use them.
>

That's really nice

>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
Option types are nice, but I feel we are going a bit off-topic. Option
types work better with other niceties like for comprehensions, pattern
matching... And I don't see PHP going that route in the near future, and
probably It's not okay for PHP to go that route...

Nullable return types is a better fit for PHP, null has been in the
language from the beginning, I agree here

Re: [PHP-DEV] [RFC] PHP Attributes

[Fleshgrinder]

On 4/22/2016 4:15 AM, Sara Golemon wrote:
> All that said, I love the proposal overall, and I can't wait to
> propose builtin annotations like <<__Memoize>>, <<__Mock>>, and
> similar.
> 

I'd rather see these two functionalities added as modifiers at the
language level instead since they change the code behavior rather
dramatically. Not sure if knowledge of them is of interest in stages
where annotations might not be readily available; this was a driving
factor in Kotlin's decision what becomes a modifier or annotation.[1]



I know that this is true for `@invariant`, `@require`, and `@ensure` as
well, they are fully-fledged assertions after all. Especially the
`@invariant` could be easily added as a magic method.

[assert]
assert.invariants = 1



Both `@require` and `@ensure` are a bit harder to implement at language
level. The following is the best I can come up with and is inspired by
the Eiffel syntax.[2]

[assert]
assert.preconditions = 1
assert.postconditions = 1

balance -= $this->balance - $sum;
  }
  require {
$sum >= 0;
$sum <= ($this->balance - self::MIN_BALANCE);
  }
  ensure {
$this->balance === (old::$balance - $sum);
  }

}

$account = new Account;

$account->withdraw(-10);
/*
Uncaught PreconditionError: $sum >= 0
*/

$account->withdraw(10);
/*
Uncaught PreconditionError: $sum <= ($this->balance - self::MIN_BALANCE)
*/

$account->deposit(10);
$account->withdraw(5);
/*
Uncaught PostconditionError: $this->balance === (old::$balance - $sum)
*/

?>

I actually think now that it would be better to go for this than for
annotations.

[1] http://blog.jetbrains.com/kotlin/2015/08/modifiers-vs-annotations/
[2]
https://archive.eiffel.com/doc/online/eiffel50/intro/language/invitation-07.html

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] PHP Attributes

[Fleshgrinder]

+1 for the basic idea, however, I have various remarks.

The RFC text is hard to read and contains many grammatical mistakes. How
could one help you here?

I think that the Hack name attributes is unintelligible and annotations
would be much clearer to any audience. Simply because the name is very
well known.

I do not see the need for multi-annotation nor multi-value support. It
just creates multiple ways to achieve the exact same thing for no good
reason.

I do not like the <<>> syntax. It requires many key strokes, is hard to
read, and looks ugly. Why not simply @ and be done with it. I am not so
sure about the bracket requirement, is it somehow required for the
parsing? Otherwise I would leave it off. I guess it might be hard to
find the end of an annotation but have you considered to use the
semicolon for that? Would align nicely with existing PHP syntax. The
following would be the ABNF for my proposal:

ANNOTATION= "@" NAME [ " " VALUE ]
NAME  = STRING
VALUE = QUOTED-STRING / PHP-CONSTANT / EXPRESSION
QUOTED-STRING = ( "'" / DQUOTE ) STRING ( "'" / DQUOTE )
EXPRESSION= PHP-CODE ";"

A semicolon would only be required if it is not a single quoted string
(see following example) or constant. A question that I see unanswered is
how embedding of variables in quoted strings should be dealt with. I see
no need for this but people might assume it is supported because PHP
supports it everywhere else.

"
class A {}

<")>>
class B {}

?>

Requiring PHP code to be terminated with a semicolon should also ensure
that people do not start to write fully-fledged programs in annotations.
Since that is not what they are intended for. An alternative approach I
see here would be to go for the brackets but then again only for PHP code:

EXPRESSION = "(" PHP-CODE ")"

Then again, it looks similar to a function call and this is imho not
good. Unless of course new annotations can be defined as special
functions directly in userland, e.g. with an `annotation function`
and/or `annotation class`. However, this would require more thought.

Another question that is unanswered for me is: how to go about adding
annotations to a complete file as is currently possible with PhpDoc and
its file-level doc block:

'
@copyright '2016 Richard Fussenegger'
@license 'MIT'

declare(strict_types=1);

namespace Fleshgrinder\PhpInternals;

@description 'True annotation support could be a very good thing.'
@invariant $this->balance >= self::MIN_BALANCE;
class Account {

  private const int MIN_BALANCE = 0;

  private int $balance;

  private Person $owner;

  @require $sum >= 0;
  @ensure $this->balance === (old::$balance + $sum);
  public function deposit(int $sum): void {
$this->balance += $sum;
  }

  @require $sum >= 0;
  @require $sum <= $this->balance - self::MIN_BALANCE;
  @ensure $this->balance === (old::$balance - $sum);
  public function withdraw(int $sum): void {
$this->balance -= $sum;
  }

  @deprecated 'for various reasons'
  public function setOwner(Person $wner): void {
$this->owner = $owner;
  }

}

@inheritDoc
class OverdraftAccount extends Account {

  private const int MIN_BALANCE = -1000;

}

?>

We also need to make sure to add something regarding coding standards
for annotation names. I would propose to go for camelCase (same as for
method names) since this is what PhpDoc used to use for many years now.

We also need to define how people can avoid to collide with internal
annotations. The typical double-underscore prefix approach that we have
for magic methods creates a lot of visual clutter and looks weird if
spread among all kinds of places. A namespace approach as we have it
already for userland code could help here.

 'user',
  'unique_constraints' => [
'name' => 'user_unique',
'columns' => [ 'username' ],
  ],
  'indexes' => [
'name' => 'user_idx',
'clumns' => [ 'email' ],
  ],
  'schema' => 'schema_name',
];
class User {}

?>

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV][RFC] Callable Types

[Nikita Nefedov]

On Sat, 23 Apr 2016 14:18:56 +0300, Dan Ackroyd   
wrote:



On 22 April 2016 at 05:12, Marcio Almada  wrote:

Hello everyone,

We just completed the draft for the "Callable Types" RFC.


There seems to be one thing missing from the RFC; please could you add
an example where the parameter and return types are also 'typed'
callables?

Presumably it would look something like this?

function reduce(int $a, int $b, callable(int, callable(int, int):int
$math):int $reducer): callable(int, int):int {
  return $reducer($a, $b);
}

Are there any limits to how far down the callable type can be defined ?

cheers
Dan


Hey Dan,

thanks for reviewing.

I have just added a paragraph about nested callables, I'll copy paste it  
here:


Nested callables can be used with no imposed limit on the nesting level.

function foo(callable(callable(int)) $cb) {
$cb(function (int $i) {
var_dump($i);
});
}

foo(function (callable(int) $intPrinter) {
$intPrinter(123);
});

There's currently no way to reference callable signature from within  
itself, meaning there's no way to make recursive signatures like below:


function bar(callable(int $number): callable(int $number):  
callable(int $number): parent_callable $recursiveCb) { // this wouldn't  
work currently

}

To add to that, nested callables can get pretty unreadable quickly, both  
of these problems would be best solved by a typedef feature of some kind,  
added to PHP later.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable Types

[Fleshgrinder]

On 4/22/2016 11:42 AM, Quim Calpe wrote:
> IMHO, the point of Optional types is the intention, if you get an
> Option from a method, you have to deal with a None branch. Of course
> you can just unwrap and go on, but it's a developer decision to do that,
> not an oversight as using a Foo|null (or ?Foo) as an object directly.
> 

IMOH, the point of ?T is the intention, if you get a null from a method,
you have to deal with a null branch. Of course you can just ignore it
and go on, but it's a developer decision to do that, not an oversight as
using a Option as an object directly.

Sorry, but this works in both directions. The problem is not null, the
problem is that there is no system that warns you (e.g. a compiler)
about the missing null check. I think that Ceylon solved this problem
extremely nicely without the introduction of something special.

function fn(): ?T {}

$x = fn();
if (is $x T) {}
else {}

Not doing as above is a compiler error in Ceylon. However, I already
wrote multiple times that there are already statical code analysis tools
available that can find exactly such things in your code. One just needs
to use them.

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV][RFC] Callable Types

[Dan Ackroyd]

On 22 April 2016 at 05:12, Marcio Almada  wrote:
> Hello everyone,
>
> We just completed the draft for the "Callable Types" RFC.

There seems to be one thing missing from the RFC; please could you add
an example where the parameter and return types are also 'typed'
callables?

Presumably it would look something like this?

function reduce(int $a, int $b, callable(int, callable(int, int):int
$math):int $reducer): callable(int, int):int {
  return $reducer($a, $b);
}

Are there any limits to how far down the callable type can be defined ?

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] PHP Attributes

[Dmitry Stogov]

On 04/22/2016 02:46 PM, Thomas Punt wrote:

Hi Dmitry!


Hi,


I would like to present an RFC proposing support for native annotation.

The naming, syntax and behavior are mostly influenced by HHVM Hack, but not 
exactly the same.

The most interesting difference is an ability to use arbitrary PHP expressions 
as attribute values.

These expressions are not evaluated, but stored as Abstract Syntax Trees, and later may 
be accessed (node by node) in PHP extensions, preprocessors and PHP scripts their selves. 
I think this ability may be useful for "Design By Contract", other formal 
verification systems, Aspect Oriented Programming, etc


https://wiki.php.net/rfc/attributes


Note that this approach is going to be native, in contrast to doc-comment 
approach that uses not well defined syntax, and even not parsed by PHP itself.


Additional ideas, endorsement and criticism are welcome.

Just a couple of comments on this:

1. I'd definitely reuse the php-ast extension for parsing the code into an
AST. It performs a number of transformations on PHP's underlying AST
that make it much nicer to use (namely better consistency). It is also
less fragile by having the abstraction between PHP's internal AST and
the AST that is exposed to userland (enabling for internal AST changes
without impacting the AST exposed to userland).

I'm not sure. Both approaches make sense.



2. You mentioned about moving some of the php-ast extension into core.
I wonder if it would be better to just move the whole extension into the
core first, and then enable this functionality if the php-ast extension is
enabled.
Even if we move php-ast into core (I think we will do it), it's going to 
be optional.

However attributes should always work.



Also, slightly tangential, but the RFC says attributes are supported on
class constants, yet doc comments (IIRC) are not. I wonder if support
for doc comments should be added for class constants?


it is already implemented.

Thanks. Dmitry.


Thanks,
Tom 



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC] Callable Types

[Nikita Nefedov]

On Sat, 23 Apr 2016 10:46:38 +0300, Jesse Schalken   
wrote:


This is great. The gaps in PHP's type annotations are slowly being  
filled.

:)

Are the rules for compatibility between callables the same rules for
compatibility between methods in classes/interfaces? Because presently,
this is allowed:

interface Test {
public function testMethod();
}

function foo1(Test $x) { }

foo1(new class implements Test {
public function testMethod(int $extraParam = 0) { }
});


but, according to the RFC, this would not be:

function foo2(callable():void $x) { }

foo2(function (int $extraParam = 0) { });


I don't see why they should be different.

I also didn't see anything mentioning reference parameters/returns. I
assume it just follows the rules for method compatibility?


Hey Jesse,

Thanks for reading the RFC.

First and foremost - no, the rules for compatibility between callables
and method implementations are different at least because our
inheritance model currently doesn't support variance for every case:

if you have

class B extends A {}

interface Foo {
function foo(B $b);
}

then implementation of `foo()` can never have `foo(A $a)` signature,
which is crucial for callables for some cases. Note that callables
have runtime variance, where classes would have compile-time variance).

So, in this way, callables have it right (it is desirable for classes
to have variance as well, but currently it's not possible as there is
a need for another compilation phase for verifying variance).

What about your case of variance with extra optional parameter, it is
actually not type safe with the current way of how PHP works (it's
covered in the end of "Variance and Signature Validation" part).
The problem lies in the notion that passing extra arguments to the
function (the ones it doesn't even expect nor use) is considered
valid and doesn't throw an error.
So if you have a function that accepts optional argument of type B and
you pass this function as a parameter of type `callable() $cb`, then
it would be perfectly valid to call it as `$cb(new A);` because you
assume that $cb is of type `callable()` and that means if you pass
anything extra - it shouldn't Fatal. But in this case it would.

While I agree that your use case is legit and ideally should be
supported, I don't think it is safe to support it until PHP deprecates
passing extra args to functions that don't expect them (which is very
troublesome to implement due to BC).

Anyway, changing this behavior of callable type later on wouldn't
break BC so the gates will still be open.

I've just added a part about references to the RFC (and found a
bug in the implementation, thanks for that =)), I'll just copy
and paste it here:

Reference parameters are supported: no variance is applied to
the fact whether parameter is referential or not.

Example:

function foo(callable(&$byref) $cb) { }

foo(function (&$bar) { }); // valid
foo(function ($bar) { }); // TypeError: Argument 1 passed to foo()  
must be callable of compliant signature: callable(&$byref), callable($bar)  
given


function bar(callable($byval) $cb) { }

bar(function (&$bar) { }); // TypeError: Argument 1 passed to bar()  
must be callable of compliant signature: callable($byval), callable(&$bar)  
given


Functions returning a reference are not different from functions returning  
a value in PHP, for the caller, hence both are interchangeable:


function foo(callable(): A $cb) { }

foo(function (): A { return new A; });
foo(function &(): A { static $a; $a = $a ?: new A; return $a; }); //  
both would pass the boundaries of a type check


(the last one has error in the current implementation, I'll fix it later)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC] Callable Types

[Jesse Schalken]

This is great. The gaps in PHP's type annotations are slowly being filled.
:)

Are the rules for compatibility between callables the same rules for
compatibility between methods in classes/interfaces? Because presently,
this is allowed:

interface Test {
public function testMethod();
}

function foo1(Test $x) { }

foo1(new class implements Test {
public function testMethod(int $extraParam = 0) { }
});


but, according to the RFC, this would not be:

function foo2(callable():void $x) { }

foo2(function (int $extraParam = 0) { });


I don't see why they should be different.

I also didn't see anything mentioning reference parameters/returns. I
assume it just follows the rules for method compatibility?

On Fri, Apr 22, 2016 at 2:12 PM, Marcio Almada 
wrote:

> Hello everyone,
>
> We just completed the draft for the "Callable Types" RFC. This RFC has been
> recently mentioned during other type related threads on this mailing list,
> so it feels to be the right time to put the proposal in context:
>
> The proposal is at https://wiki.php.net/rfc/callable-types
>
> The W.I.P patch is available for testing through http://3v4l.org under the
> RFC tab.
>
> We count with your detailed feedback and insights. Let's have a nice,
> respectful and
> constructive conversation about the RFC and work on possible improvements!
>
> Thanks
> Nikita Nefedov
> Márcio Almada
>