> On Mar 10, 2021, at 12:06 PM, Matthew Brown wrote:
>
> Hey,
>
> Ondřej Mirtes and I present an RFC for the noreturn type:
> https://wiki.php.net/rfc/noreturn_type
>
> The feature already exists in Hack (the primary inspiration) and is
> currently supported by our static analysis tools insid
Hi Dan,
We have no commercial purpose on the swoole open source project. This is a
purely technical project.
If possible, we can remove the name of swoole, contribute the source code of
swoole-src to php-src, and transfer the copyright.
Here is just a technical discussion. My opinion is that i
Thank you for providing me with the feedback, experts! Initially, I wanted
empty returns in void functions. When I prepared the request, I included the
other solutions that I felt important and worth adding. Is it not possible to
go with empty returns in void functions? I agree that the code can
> On Mar 11, 2021, at 10:41 AM, Ben Ramsey wrote:
>
>> On Mar 11, 2021, at 10:29, Aaron Piotrowski wrote:
>>
>> There is not an internal API to create fibers at this time. However, I
>> planned to collaborate with other internals developers to add this API (and
>> of course with feedback fr
On 11 March 2021 19:39:26 GMT, Dan Ackroyd wrote:
>Unfortunately people in the community have started doing what I
>feared, and using void as 'no value is returned', which is not what
>the language actually _does_.
>
>I realise the above might be slightly discombobulating if, for
>example, some pe
Hi Dan,
While I have some sympathy for your first point:
>I (and others) brought this up during the void RFC:
>https://news-web.php.net/php.internals/88990 and said that null was
>the right choice over void, as it matches what the language actually
>does.
I disagree with your second, which doesn
Hi Twosee, Tianfeng.Han
I was drafting a longer reply to you both, but I realised I might be
missing some information.
Please could you disclose the commercial interests of the Swoole
maintainers, and the ties to the for profit companies that provide
services implementing Swoole?
Having people v
Hi Matt & Ondřej,
One of the things that makes PHP different from other languages (and
for better for a change) is that every function returns a value, even
where there is no explicit return statement.
This eliminates a large number of edge-cases in code like:
function log_result(mixed $bar) {
Am 11.03.2021 um 17:51 schrieb Chase Peeler :
> If someone is willing to do the work to
> add this to core, we aren't trading off other features in order to add it,
> and it doesn't cause BC breaks or other bugs, what is the reason to not add
> it?
Complexity, which might come back and bite us in
On Wed, Mar 10, 2021 at 10:51 PM Kalle Sommer Nielsen wrote:
> Den ons. 10. mar. 2021 kl. 20.22 skrev Dan Ackroyd >:
> >
> > Hi internals,
> >
> > Well, technically this is addressed more to people who read internals.
> >
> > Please don't contact people off list putting pressure on them to vote
> On Mar 10, 2021, at 10:37 PM, office.hamzaah...@gmail.com wrote:
>
> Hello Internals,
> I congratulate you for the successful release of PHP 8.0.3. I also
> appreciate your efforts to bring union types and return type hints.
> Although the type hints have made debugging more easier, it has creat
On Thu, Mar 11, 2021 at 10:37 AM Larry Garfield
wrote:
> On Thu, Mar 11, 2021, at 6:10 AM, Hamza Ahmad wrote:
> > Hi Victor,
> >
> > It does not contradict because it does not cover two different aspects.
> > First, return types specify the types of to be returned values. Second,
> > this request
On Thu, Mar 11, 2021 at 8:56 AM 韩天峰 wrote:
> Hi,
> I am come from Chinese, we may have some cultural differences, and there
> may be some difficulties in communication. I try to express my opinion.
> To be precise, the fiber can only be used for amphp and reactphp or other
> event-driven asynchro
> On Mar 11, 2021, at 10:29, Aaron Piotrowski wrote:
>
> There is not an internal API to create fibers at this time. However, I
> planned to collaborate with other internals developers to add this API (and
> of course with feedback from swoole developers), so this will be a feature
> available
> On Mar 11, 2021, at 7:56 AM, 韩天峰 wrote:
>
> The RFC does not mention how an extension uses fiber.
>
Hi,
I forgot to address your point that the RFC does not mention how an extension
uses fibers.
I did omit this from the RFC as I focused on the user API, as that is typically
what PHP RF
> Hi all!
>
> A concern was raised off list that due to the complexity of the way this
> feature interacts with the engine, it may be best to mark the feature as
> experimental. This would allow some changes to be made to certain edge-case
> behaviors and, while I don't think it would be nece
> On Mar 11, 2021, at 7:56 AM, 韩天峰 wrote:
>
> Hi,
> I am come from Chinese, we may have some cultural differences, and there may
> be some difficulties in communication. I try to express my opinion.
> To be precise, the fiber can only be used for amphp and reactphp or other
> event-driven as
On Thu, Mar 11, 2021, at 6:10 AM, Hamza Ahmad wrote:
> Hi Victor,
>
> It does not contradict because it does not cover two different aspects.
> First, return types specify the types of to be returned values. Second,
> this request proposes a shorthand technique to avoid writing a single
> line
Hi,
I am come from Chinese, we may have some cultural differences, and there may be
some difficulties in communication. I try to express my opinion.
To be precise, the fiber can only be used for amphp and reactphp or other
event-driven asynchronous IO frameworks developed using php. The RFC does
Hi Nicolas and Claude,
First of all, thanks for your comments! Let me answer them one by one:
1.) A few other people off-list also shared their negative feelings about
the E_STRICT. So I'm ok to use E_DEPRECATED instead.
Now that I implemented the suppressing mechanism, I think using a separate
e
Hi Peter and internals
> On 11 Mar 2021, at 07:51, Peter Stalman wrote:
>
> On Wed., Mar. 10, 2021, 11:22 Matthew Brown,
> wrote:
>
>> If a significant number agree I can add a secondary vote on noreturn vs
>> never, but never introduces more of a BC risk.
>>
>
> Hi Matt,
>
> I like this RF
Hi Victor,
It does not contradict because it does not cover two different aspects. First,
return types specify the types of to be returned values. Second, this request
proposes a shorthand technique to avoid writing a single line code multiple
times. Third, it is similar to default argument val
Hey Aleksander,
On Thu, Mar 11, 2021 at 8:25 AM Aleksander Machniak wrote:
> On 10.03.2021 20:28, Ben Ramsey wrote:
> >> I don't like that type covariance would be allowed. Why such an
> >> exception to the rules?
> >
> > It’s not an exception. Returns are covariant. Parameters are
> > contravar
IMO this feature would contradict with the Single Responsibility Principle.
Type hints are for type hinting, not for value hinting. Cheers.
Sent from Mailspring
(https://link.getmailspring.com/link/4d67851f-de69-45d9-9db1-54b16845e...@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%
Hi Rowan,
Thanks for the response. Luckily, you razed the question that I thought about
after posting the first request.
My idea develops on respecting both return type hints and union types. The
current implementation of empty return does not respect the function signature.
As I have mentioned
Hi Dmitry,
I can confirm that it works locally again too now.
cheers,
Derick
On Wed, 10 Mar 2021, Dmitry Stogov wrote:
> This is fixed in master.
>
> Thanks. Dmitry.
>
> On Fri, Mar 5, 2021 at 4:43 PM Dennis Birkholz
> wrote:
>
> > Hello,
> >
> > I was also able to reproduce the error.
> >
On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:
>function get_nationality_string(int $country_code) : string | "unknown"
>{
> return;
>};
If I understand you correctly, your idea is that the "return;" here would be
treated automatically as "return 'unknown';" I think that'
Am 10.03.2021 um 19:06 schrieb Matthew Brown:
Ondřej Mirtes and I present an RFC for the noreturn type:
https://wiki.php.net/rfc/noreturn_type
Thank you, Ondřej and Matt, for bringing this up. Makes sense to me, +1.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi Aleksander
> I see it's a subtype, I don't get why. Wouldn't it be better to be a
> separate type so return type covariance is not allowed (as it is with
> void)? Was it a design decision or a side product of the implementation?
This is a fairly common technique. For example, this is from the
29 matches
Mail list logo
