Re: [PHP-DEV] Re: [RFC][Discuss] Arrow Functions

I like the suggested syntax. The only drawback I see is that it inhibits the future addition of union types for closures:     |int | float $x| => $x Adding parentheses of course resolves the issue but looks a bit awkward:     |(int | float) $x| => $x Apart from that I have nothing to complain

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

I agree. Using the prefix `function` kind of defeats the purpose of the whole RFC. There are three things that contribute to the boilerplate of closures: - The `function` keyword - The `return` keyword - The `use` clause The RFC eliminates two and reduces one to about 25%. I also

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

Hey everyone I’m on team C as well. One complaint about the RFC is that it doesn’t support multi-statement bodies. Arrow functions are especially useful for functional programming where it’s common to return a value in a single expression. Using multiple statements (partly) destroys the

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

Hey Stephen > You don't *have to* specify types at all. If you want to use PHP without > verifying/requiring types, thats your prerogative, but given the recent > improvements to allow scalar type hinting, I think it’s a mistake to say that > *any* use of type hints is “not recommended”. Sure

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

Ah, my example was of course wrong again -.- The caller should’ve looked like this (although I think you get the point): ```Swift fetchUsers { users in    // `users` is inferred to be an array of `User`s } ``` Regards On 4 Feb 2017, 16:41 +0100, ilija.tov...@me.com, wrote: > Hey Stephen > > >

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

Hi Stephen > Using type hints is a part of the language. It even has benefits that I can > absolutely see being used here: > > array_map(function(Foo $x) => $x->bar()); > > If Foo is a class/interface with a method of bar, your IDE can know that it's > a valid method to call. > > That of course

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

Hey Stephen > You’re really starting to lose me now. You want types but don’t want to > define them, and you’re somehow mixing phpdoc into this. Because we use PHPDoc to provide type hints to the IDE where PHP doesn’t support them yet (variables and properties). > Currently PHP has zero

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

> I personally don’t see a huge use for this in my own work actually, I’m just > trying to make sure that something I will likely have to live with from > *other* developers isn’t impossible to read, that’s all. But I agree that > most people seem focussed on the actual syntax. Well, I do. We

[PHP-DEV] wiki.php.net access

Hi there! I just singed up at https://wiki.php.net . It instructed me to write a quick E-Mail to this address to prove I’m human. My username is: ilijatovilo Basically, I’ve been working with PHP professionally for quite a few years. The thing I’m mostly interested in is

[PHP-DEV] Introduction to the PHP source code

Hi everyone! I’d like to get familiar with the PHP C code base so that I can contribute back to the community and maybe even implement a small RFC at some point when I feel comfortable enough. Looking at the giant repository I feel a little overwhelmed. Is there a place where I can get

Re: [PHP-DEV] Revisit RFC “Property Accessors Syntax 1.2”

Now that PHP 7 is here, one step backwards (performance wise) might not matter as much as it did before. Others might still disagree though. I'd be interesting to hear if the people who voted against the RFC because of the performance penalty still feel the same now that PHP 7 is here.

[PHP-DEV] Revisit RFC “Property Accessors Syntax 1.2”

Hi everyone There was an RFC about a C#-like property syntax almost four years ago that got declined: https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 It failed by only 2-3 votes. In my opinion, PHP is still in need of this feature as it would make the language much more expressive. Let me

Re: [PHP-DEV] Revisit RFC “Property Accessors Syntax 1.2”

I see, that makes a lot of sense. Sadly, I am neither a C developer nor do I understand the PHP interpreter codebase in the slightest. At least I now understand why the RFC was rejected, maybe that will comfort me when I cry myself to sleep tonight :P On 19 Dec 2016, 23:47 +0100, Larry

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

Hi Rowan I see. I still think a simple poll would be useful to choose the least controversial syntax. Otherwise I fear that the RFC might get rejected out of superficial reasons. Regards, Ilija On 7 Feb 2017, 21:07 +0100, Rowan Collins , wrote: > Hi Ilija, > > On 7

[PHP-DEV] String interpolation shortcomings

Hi everyone String interpolations are a great feature. They make your code more readable and can reduce the number of allocations PHP has to make. Unfortunately, PHP is very restrictive in what kind of expressions string interpolation accepts. The only time you can actually use it is if your

Re: [PHP-DEV] String interpolation shortcomings

Oops, I actually meant to suggest the syntax `“Hello \{world()}”` (note: curlies instead of parens) to be closer to the original syntax. Regards, Ilija On 11 Jul 2017, 21:10 +0200, ilija.tov...@me.com, wrote: > Hi everyone > > String interpolations are a great feature. They make your code more

Re: [PHP-DEV] Change -> to dot(.)

The dot is already the string concatenation operator. This would be a horrible migration process. The PHP team is never going to upset the developer experience that much for a purely cosmetic change. Also, C and C++ use the -> symbol, two major languages. Regards On 6 Jul 2017, 08:13 +0200,

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

of curly braces around the body would look pretty messy.     $things->forEach({$v => { foo($v); bar($v); }}); On Mon, Jun 19, 2017 at 4:43 PM, Levi Morrison <le...@php.net> wrote: On Sun, Jun 18, 2017 at 1:44 PM, Ilija Tovilo <ilija.tov...@me.com> wrote: Sorry, I wasn’t aware

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

My preferences: 1, 3, 4, 5, (big void),  2. I actually like 4 the most but I get that that might not be practical if it leads to unexpected behaviour. I can’t think of a scenario where capturing by reference would be helpful in a single line closure. 5 just adds additional complexity with no

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

y looks pretty awkward in namespaces, this won't help. > > > On Sun, Jun 18, 2017 at 12:58 PM, Ilija Tovilo <ilija.tov...@me.com> wrote: > >> The backslash has actually been one of the earlier options if I remember >> correctly. >> I definitely prefer the `fn`

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

ing to the visual ambiguity - the fn($x) part of the syntax is > indistinguishable from a function-call. > > > On Sun, Jun 18, 2017 at 8:42 PM, Ilija Tovilo <ilija.tov...@me.com > <mailto:ilija.tov...@me.com>> wrote: > > I don't agree that the fn keyword solves

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

The backslash has actually been one of the earlier options if I remember correctly. I definitely prefer the `fn` keyword as it’s only one character more but adds a better visual hint to the arrow function. I’m also not sure why we’d choose a different arrow (`==>` or `~>`) when the ambiguity

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

I think it’s worth noting that the people most excited about arrow functions are probably the ones with a more functional approach. Those kinds of side effects are usually avoided. I also have nothing against capturing by reference. Given the last example: fn($item) => $array[] = $item All you

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Hi Sara That is indeed a very good point. Haven't thought of that one. Regards > On 15. Sep 2017, at 19:50, Sara Golemon wrote: > >> On Fri, Sep 15, 2017 at 1:35 PM, wrote: >> The `extract` function takes an associative array and >> puts it into the

[PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Hi! The `extract` function takes an associative array and puts it into the local symbol table. http://php.net/manual/en/function.extract.php ``` $array = [     ‘foo’ => ‘foo’,     ‘bar’ => ‘bar’, ]; extract($array); print $foo; // "foo" ``` As a second parameter the `extract` function takes

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Dude, calm down. This was a request for feedback. As other people have pointed out before it may not be the best idea to remove it since there’s no good way to write the equivalent code in PHP. No reason to be rude. On 16 Sep 2017, 11:42 +0200, li...@rhsoft.net , wrote: > > >

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

That’s fine, I have no problem with feedback. I changed my mind once other people pointed out the flaws in my thinking. Politely. Sorry for spending my free time thinking about how to make PHP better. I’m not claiming to be an expert in any means, hence the RFC. On 16 Sep 2017, 11:49 +0200,

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Again, tell me I'm wrong. I have no problem with that. After all I'd still need 50%+ of people with voting privileges to agree with me which is rather unlikely if it has major flaws. I don't claim to know it all, you don't need to get rude for me to listen. As soon as you do that the

Re: [PHP-DEV] [RFC] Consistent null behaviour

I realized after sending the initial E-Mail that there might be more breaking changes than I thought, like the one you suggested. The same thing actually happens for bools, ints and floats: https://3v4l.org/jvVbO I wouldn’t depend on this behaviour since you’d get errors depending on what is

[PHP-DEV] [RFC] Consistent null behaviour

Hi everybody! To my surprise, I noticed today that an array access on a `null` value returns `null` without any warning whatsoever. Accessing the property of a `null` value gives you a notice, while calling a function on that `null` value gives you a fatal error. https://3v4l.org/ZSZHN This

Re: [PHP-DEV] Confusing type mismatch error messages

> And actually, I still would be surprised to see such an error message. This happens when you annotate your function incorrectly: https://3v4l.org/CoUss On 20 Sep 2017, 19:08 +0200, Christoph M. Becker , wrote: > On 20.09.2017 at 18:54, Derick Rethans wrote: > > > On Wed, 20

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Hi Stas Dangerous meaning that if given untrusted input someone could mess with the behaviour of your code. There are risks and benefits to every solution. Certainly you’d agree that in some cases the risks outweigh the benefits. As Sara pointed out, this might not be the case here as there’s

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Hi Yasuo These sound good to me! There’s still a smaller vulnerability of defining variables beforehand: ``` $data = ['hasAccess' => true]; export($data); if ($user->isAdmin()) {     $hasAccess = true; } if (isset($hasAccess) && $hasAccess === true) {     print 'Bingo'; } ``` but code like

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Hi Marco I can see it’s usefulness in this case. But wouldn’t it be better to implement this by hand in these rare cases (it’s 3 lines of code) instead of encouraging the pollution of the symbol table by unknown input? It’s also clearer since people who don’t know the `extract` function

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

Hi Ryan I can see your argument. The reasoning behind it is that a function in the standard library should not encourage unsafe code. Admittedly, since this function is rarely used except for templating systems one could call this a non-issue. I just wanted to bring it up. Regards On 15 Sep

Re: [PHP-DEV] [RFC] Deprecate the extract function in PHP 7.3

> no, as there is no special risks There certainly is. No other function (as far as I’m aware) mutates your local symbol table. This means you need to know exactly what symbols are defined and what kind of data you’ll receive when calling `extract`. So basically this is only safe right at the

Re: [PHP-DEV] [RFC] Pre-draft for PipeOp v2

Agree. Even if we already had partial application the previously suggested syntax is still more readable IMO. Consider the following example: ``` $array   |> array_map(function ($element) { ... }, $$); ``` vs ``` $array   |> apply(flip('array_map'), function ($element) { ... }); ``` Not to

Re: [PHP-DEV] Re: [RFC] Match expression

Hi Tony > … you sometimes forget to insert a break statement then that is your fault. Any bug in your source code is ultimately your fault. But as mentioned before human error is inevitable. You can make it easier for your users to make less mistakes though. Other languages (e.g. Rust or

Re: [PHP-DEV] Re: [RFC] Match expression

> it makes it impossible to group several conditions with a single break In Swift you can group multiple conditions with a comma `,` and in Rust with a pipe `|`. Here’s how that could look in PHP: ```php match ($x) {     1, 2: ‘One or two’; } ``` The only thing you cannot do is this: ```php

Re: [PHP-DEV] Re: [RFC] [Discussion] Operator functions

I also love this idea! This and short arrow functions and I’m golden (in terms of closures at least) :) Regards On 9 Sep 2017, 03:31 +0200, Tom Worster , wrote: > On 8 Sep 2017, at 17:41, Andrea Faulds wrote: > > > Hi everyone! > > > > Here's an RFC for a small, simple,

Re: [PHP-DEV] Re: [DISCUSSION] Match expression

Hi Andrea > Well, I don't think we have any other expressions that are also > statements with very slightly different syntax The syntax isn't actually different. We don't have different grammar for the match statement and expression. There's only one. Think of it more like a type check. In other

Re: [PHP-DEV] [DISCUSSION] Match expression

> Please, pull that part out. Guys. You've made your opinions loud and clear. But I'm not just building this for you, I'm also building it for others and myself. > With it, it may pass or not, but it would be a weaker proposal. Maybe, maybe not. You're assuming people will share your opinion

[PHP-DEV] [DISCUSSION] Match expression

Hi internals I'd like to announce the match expression RFC that replaces the switch expression RFC I announced a few weeks ago. New: https://wiki.php.net/rfc/match_expression Old: https://wiki.php.net/rfc/switch_expression Due to the feedback I decided to take the RFC in a slightly different

Re: [PHP-DEV] [DISCUSSION] Match expression

Hi George I appreciate your feedback. > One small decision that I personally disagree with is the usage of `=>` > compared to using the colon as the switch statement does. I picked the `=>` symbol because IMO the extra spacing and wider symbol visually separates the two sides better. The

Re: [PHP-DEV] [DISCUSSION] Match expression

Hi Iván > Would be posible for blocks to require a return statement instead of raising > an error? It would be possible for the blocks to return values (though not with the return keyword). I've created a small prototype a few weeks ago: ``` $result = match ($x) { 0 => { echo

Re: [PHP-DEV] [DISCUSSION] Match expression

Hi Rowan > Can match arms contain other flow control, such as "return" or "continue"? Yes and yes. They behave exactly the same as in the switch. This should definitely be described in the RFC. > Can I mix a bare value and a block as arms of the same match, or does the > whole construct need

Re: [PHP-DEV] [DISCUSSION] Match expression

Hi Larry > That not only alleviates the need to support multi-line blocks, it keeps the > match statement itself clearer to understand at-a-glance, and encourages the > definition of named, testable, small blocks of code (ie, functions whether > anonymous or not), which is a net win on its

[PHP-DEV] Re: [DISCUSSION] Match expression

Hi internals Just a heads up, I'd like to start the voting on the match expression RFC in a couple of days. https://wiki.php.net/rfc/match_expression I have made a number of changes to the RFC. * Block return values are now allowed but limited to match arms

[PHP-DEV] RFC Throw expression was accepted

Hi internals I closed the votinng on the throw expression RFC. https://wiki.php.net/rfc/throw_expression It was accepted with 46 Yes and 3 No votes. Thanks to everybody who participated! Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [DISCUSSION] Match expression

Hi Rowan If we were to remove blocks we'd probably also reconsider other things (namely the optional semicolon and break/continue) and many examples in the RFC would become invalid and irrelevant. This would probably lead to even more confusion which is why I will most likely not move blocks to

Re: [PHP-DEV] [DISCUSSION] Match expression

Hi Rowan > That means if we want to add a way to get a value out of a statement block, > we can't use "return"; and if we want to add explicit fallthrough, we can't > use "continue". And we probably shouldn't do that. return means return from the function, it makes little sense to change it in

Re: [PHP-DEV] [RFC][POLL] Switch expression

Hi internals After Levis email yesterday we discussed his suggestions in private. I did some investigation and did find a way to reuse the current switch syntax. The main problem of the ambiguity was the empty switch statement vs expression: ``` // Could be a switch expression or a switch

[PHP-DEV] [VOTE] throw expression

Hi internals, I hope you're doing well. I have opened voting for the throw expression RFC. https://wiki.php.net/rfc/throw_expression Voting closes on April 19th, 2020. Regards, Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] throw expression

Hi Dan > Did the RFC get updated to address this? > > As the current behaviour listed* in the RFC seems wrong and surprising to me. I did respond to that e-mail but probably got classified as spam as were the other e-mails I sent with that address. This was my response: > I've thought about

Re: [PHP-DEV] [VOTE] throw expression

Hi Nikita > The only thing wrong here is calling this an "exception to the rule" in the > RFC. This is completely standard and expected behavior given the specified > precedence. It is in the nature of precedence that there will always be cases > where the use of () is required, and this is

Re: [PHP-DEV] [VOTE] throw expression

Hi George > Maybe I'm out of the loop but I haven't seen this before It's my fault, my e-mails went to the spam folder for many people. I'm sending my e-mails from a different address now which seems to have resolved the problem. > What is the limitation leading to this behaviour? It's to

Re: [PHP-DEV] [VOTE] throw expression

Sorry Dan, at the time I sent this e-mail I wasn't aware you wouldn't receive it. After not hearing from you I assumed you were ok with my response. > The issue is that as your words are written, it is not possible for me > to understand exactly what you mean. To be fair, you omitted the next

Re: [PHP-DEV] [RFC] switch expression

Hi Dennis Thanks for your feedback! > you can fall through to other cases without break You could do the same using the || operator. > what about the default case? I haven't described the default case in my proposal but it is exactly what you'd expect it to be: ```php $var = true switch {

Re: [PHP-DEV] [RFC] switch expression

Hi Rowan > The problem with that is that it requires a temporary variable to be > switched on. If I want to switch on, say, a method call, I can write this > for equality: I agree. The iffy part would be recognizing if the case expression should be equated to the switch input or evaluated on

Re: [PHP-DEV] Re: [RFC][DISCUSSION] throw expression

Hi Andrea > but I am surprised you haven't mentioned the `and` and `or` operators I did mention them in the RFC here: https://wiki.php.net/rfc/throw_expression If this RFC is accepted they will indeed be possible __ Regards -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] [RFC][DISCUSSION] throw expression

Hi Andrea > I would think we can just give `throw` an appropriate precedence so that > expressions like the above do what is desired The example are taken from the RFC online. The following expression is already possible: ```php throw $condition1 && $condition2 ? new Exception1() : new

[PHP-DEV] semicolon terminator for switch cases

Hi internals Looking through the language grammer I discovered that switch cases can also be terminated with a `;` instead of a `:`. ``` switch ($i) { case 1; return 1; default; return 2; } ``` https://3v4l.org/o7nD8 This is in fact documented:

Re: [PHP-DEV] Re: semicolon terminator for switch cases

Hi Andrea The reason this doesn't work anymore: ``` If (false); echo 'Test'; endif; ``` Is because the semicolon is an empty statement: https://github.com/php/php-src/blob/9e77d5a9da9e80a1bfe226f60ccb12fd8bf9481c/Zend/zend_language_parser.y#L457 This is still valid code: ``` If (false);

Re: [PHP-DEV] [RFC] switch expression

Hi Gabriel > This doesn't look like it can do fallbacks which are traditional feature of > switch statements, can it? You can take a look at the tests to get a feel for what it’s like: https://github.com/php/php-src/pull/5308/files Multiple conditions are possible: ``` return

Re: [PHP-DEV] [RFC][POLL] Switch expression

Hi Rowan I agree that the structure of the RFC is sub optimal. Honestly, I've rewritten and moved things at least 5 times and it's still not good. I'll see how I can improve it. > so we could maybe combine them with the break keyword: > > $y = switch ($x) { > case 0: > break 'Foo';

Re: [PHP-DEV] [RFC] switch expression

Thanks for your feedback, Larry! > One possible improvement to either version is allowing an expression on the > left side. That is, rather than doing an equality match, do a boolean match. This is how Rust does it: ```rust let x = match ... { Some(y) if y < 5 => ... } ``` In other

Re: [PHP-DEV] [RFC] switch expression

Hi Michał I’m sorry, unfortunately I missed your e-mail and RFC. Let me know if you’re still working on it and I’ll back off of course. Regards

[PHP-DEV] [RFC][DISCUSSION] switch expression

Hi internals Apparently my previous emails were classified as junk (very flattering). Hopefully that issue is fixed now. I'd like to move the RFC switch expression to "under discussion". It tries to address some of the common issues with the switch statement by introducing a new switch

Re: [PHP-DEV] [RFC][DISCUSSION] switch expression

Hi Arnold > However, operations don't ever throw exceptions, but throw an error instead. I replaced it with a new, more fitting UnhandledSwitchCaseError. Thanks! Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][DISCUSSION] switch expression

Hi Dan First of all, thank you for your feedback. I appreciate your time. I think it's worth noting that the switch expression solves the problems it does implicitly, not directly. 1. Returning values: Of course, this is the main argument for the switch expression (regardless of the other

[PHP-DEV] [RFC][POLL] Switch expression

Hi internals A few days ago I opened the discussion on the switch expression RFC: https://wiki.php.net/rfc/switch_expression There's been a fundamental disagreement on what the switch expression should actually be. Due to the conflicting feedback I no longer know how to proceed. This is why I've

Re: [PHP-DEV] [RFC] switch expression

Hi Stanislav > I'm still not sure why if we're calling it "switch" C# does it. Not to say everything they do is right but it's reassuring that a big company like Microsoft had the same approach. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/switch

Re: [PHP-DEV] [RFC] switch expression

Hi Larry Thanks for your suggestion. I chose to use switch instead of match for a couple of reasons: 1. It uses the same AST, code generation and opcodes as the switch, I don't agree that it is significantly different than the switch that we already have. 2. Adding the `match` keyword is a

Re: [PHP-DEV] [RFC] switch expression

> Having two syntaxes for one keyword is not a good idea, We're already doing that. What about classes vs anonymous objects? Functions vs closures? They're using the same keywords. There's no confusion. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] [RFC] switch expression

Hi Larry > Not everything has to be a statement. This is not what I meant. What I meant is that it should be usable in a statement context. Since you mentioned Rust, match is always an expression. But you can use it without making use of the return value. This is what I'm suggesting. In PHP this

Re: [PHP-DEV] [RFC][DISCUSSION] throw expression

On 22.03.20, 18:17, "Dan Ackroyd" wrote: > $condition || throw new Exception('$condition must be truthy') > && $condition2 || throw new Exception('$condition2 must be truthy'); > > The "Deprecate left-associative ternary operator"* RFC made it so that > parentheses are required when ternary

[PHP-DEV] [RFC] switch expression

Hi everybody! A few years ago I suggested adding a new `match` expression to the PHP language: https://externals.io/message/100487 I arrogantly assumed someone will implement it for me which of course didn't happen. I'd finally like to get my own hands dirty. I have a very rough,

Re: [PHP-DEV] Re: [RFC] Constructor Property Promotion

Hi Nicolas > I would expect attributes to apply only to the properties on my side. Parameter annotations could be interesting for dependency injection. Symfony currently has some DI magic through parameter names among other things. It might be nice to control these through annotations instead.

Re: [PHP-DEV] [VOTE] match expression

Hi Dan > I like this idea, and would like to see 'match' in PHP. At the same > time, is there any need to have the vote right now? The deadline for > PHP 8 feature freeze is July 27 2020. I understand you sentiment. Let me put it this way: I've announced the first version of this RFC four weeks

[PHP-DEV] [VOTE] match expression

Hi internals I have opened the voting on the match expression RFC. It will end on 9th of May, 2020. https://wiki.php.net/rfc/match_expression Here are the last changes: In the last update I mentioned allowing return values in blocks. Unfortunately, we discovered some technical difficulties

Re: [PHP-DEV] [VOTE] match expression

> Or for that matter... is anyone actually using that syntax in the wild, or is > it hypothetical? It's quite common in C (you can't declare variables directly in a switch case) so I'd guess it would be used at least by some people in PHP. The worst part is that your code wouldn't throw, it

Re: [PHP-DEV] [RFC] Mixed type

Re: [PHP-DEV] [RFC] Mixed type

Sorry, I don't know what's wrong with my mail client, it just sent the email with no content. Here's it again. Hi Dan > Here is an RFC for adding a 'mixed' type to the language: > https://wiki.php.net/rfc/mixed_type_v2 > The RFC builds on an earlier draft by Michael Moravec. I don't have a

Re: [PHP-DEV] Re: [DISCUSSION] Match expression

Hi Dan > I don't think PHP can guarantee to detect duplicate conditions This warning is only shown if duplication is guaranteed, namely when a jumptable is generated. Which also makes the check fairly cheap. > Would the duplicate condition* below be detected? No, as jumptables are only

Re: [PHP-DEV] [VOTE] match expression

Hi Nikita Thank you for your analysis. That's something I should've done as part of the RFC. I can only share my personal motivation for creating this RFC. Some people will disagree. > Is match intended as a replacement for switch? To me, match is primarily a switch alternative with safer

Re: [PHP-DEV] [VOTE] match expression

Hi someniatko I think you have a firm grasp of the key issues but I don't agree with your conclusion. > Problem no. 2 could be addressed by > allowing "complex" expressions consisting of, potentially, few > statements, language-wide, solving the issue both for short closures > and for `match` I

Re: [PHP-DEV] [DISCUSSION] Match expression

Hi Nikita > I think part of the problem is that it's a case of either / or. I agree that your example is an unpleasant limitation. > I'm not quite sure what the way forward regarding that is. I can understand > the reluctance to propose the Rust-style block expression syntax, given its >

Re: [PHP-DEV] [DISCUSSION] Match expression

> Firstly, block expressions are a foundational part of the Rust > language, not a special case used in only one place. >From a previous e-mail: > It would be possible for the blocks to return values (though not with > the return keyword). I've created a small prototype a few weeks ago: > >

Re: [PHP-DEV] Re: [DISCUSSION] Match expression

Hi Andrea I realize there's a lot of noise in the mailing list right now, I'll keep this my only e-mail for today. > I share others' concern that it is inconsistent with PHP's > existing statements Can you elaborate on what exactly the concerns are? Note that even if we added block expressions

Re: [PHP-DEV] [DECLINED] match expression RFC

Hi Jakob > If you're sure you're not going to pursue one of these options, maybe > let us know, so someone else can give it a go based on your excellent > work and while it's still fresh :-) I'm working on a second draft with the following changes: 1. Blocks were removed 2. Secondary votes were

Re: [PHP-DEV] [DECLINED] match expression RFC

Hi Kralle > Whether or not your new RFC qualifies for the second part of this is > rule, I can't tell as its left vaguely defined and I can't recall it > being used besides the scalar type hints RFCs. Perhaps someone smarter > than me can phrase this better. The docs say the following: > The

Re: [PHP-DEV] [RFC] Guard statement

Hi Pavel > https://wiki.php.net/rfc/guard_statement > First of all, thanks for your proposal! I'm a bit skeptical. guard is mostly useful in Swift because it's a strictly typed language. let x = foo() // type Int? if x == nil { return } // x is still

Re: [PHP-DEV] [RFC] Guard statement

Correction: > guard (null !== $x = foo()) { return; } > // No benefit over > if (null !== $x = foo()) { return; } My example was wrong, should've been: > if (null === $x = foo()) { return; } -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

[PHP-DEV] [DECLINED] match expression RFC

Hi internals I closed the vote on the match expression RFC. https://wiki.php.net/rfc/match_expression First of all, thank you to everybody who participated! It was declined with 28 no and 6 yes votes. There were three main criticisms: 1. The RFC wasn't discussed extensively enough and too many

[PHP-DEV] [RFC] throw expression

Hi everybody! Yesterday I stumbled upon this Tweet by Nikita: https://twitter.com/nikita_ppv/status/1240309838950866946 It answered why this seemingly correct block of code doesn't work:     fn() => throw new Exception('nope'); The answer is rather simple. `throw` is a statement,

[PHP-DEV] RFC karma

Hi! I need RFC karma to create the RFC I mentioned in the internals list yesterday: https://externals.io/message/109156 Can somebody give me those permissions? Thank you!

[PHP-DEV] Re: RFC karma

Thank you Christoph! On 21.03.20, 10:05, "Christoph M. Becker" wrote: On 20.03.2020 at 19:27, Ilija Tovilo wrote: > I need RFC karma to create the RFC I mentioned in the internals list yesterday: > > https://externals.io/message/109156 >

[PHP-DEV] [RFC][DISCUSSION] throw expression

Hi everybody! I hope you’re doing well. Due to the modest feedback I’d like to move the throw expression RFC to “under discussion”. https://wiki.php.net/rfc/throw_expression In short, the RFC proposes to convert the throw statement into an expression to make it usable in arrow

Re: [PHP-DEV] [RFC][DISCUSSION] throw expression

Hi Dan Interesting suggestion. I'll have to think more about how many of these variations there are and if there's an easy way to recognize them. Ilija On 22.03.20, 18:16, "Dan Ackroyd" wrote: On Sun, 22 Mar 2020 at 16:17, Ilija Tovilo wrote: > > Due to the mod

Re: [PHP-DEV] [RFC][DISCUSSION] throw expression

personally don't think it's a good fit for PHP because PHP can't enforce you to handle these cases. Regards On 22.03.20, 19:14, "Mike Schinkel" wrote: > On Mar 22, 2020, at 1:16 PM, Dan Ackroyd wrote: > > On Sun, 22 Mar 2020 at 16:17, Ilija Tovilo wrote:

  1   2   3   4   >