Re: [PHP-DEV] Null-safe property access in interpolated strings
On Sun, Aug 9, 2020, 00:17 Sara Golemon wrote: > Do we expect this to work? > > $foo = new stdClass; > $foo->bar = "Hello"; > echo "$foo?->bar world\n"; > > Because at the moment it doesn't: https://3v4l.org/nLv3l > > -Sara > Ooof, people still interpolate strings that way? Good riddance if it doesn't work: this code is questionable (and not just because of the question mark in it) >
Re: [PHP-DEV] Re: [VOTE] nullsafe operator RFC
Hi Ilija Tovilo, > > I just noticed that while we support "$a->b", we do not support "$a?->b" > > (the quotes are relevant -- I'm talking about interpolated strings here). > > That is, in the latter case the "?->b" is just treated like a string part, > > not like a property access. > > Just as I sent this I realized this is technically a breaking change, > probably a small one but still worth mentioning. I'm now also not > totally sure if we should change it at this point. Let me know what > you think. To me, that sounds like a reasonable bugfix for 8.0 and something most applications wouldn't be using before php 8.0. I'd missed whether the RFC mentioned it or not. - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] nullsafe operator RFC
On Sat, Aug 8, 2020 at 3:42 PM Ilija Tovilo wrote:
> > > I just noticed that while we support "$a->b", we do not support
> "$a?->b" (the quotes are relevant -- I'm talking about interpolated strings
> here). That is, in the latter case the "?->b" is just treated like a string
> part, not like a property access.
> > >
> > > I don't think the behavior for this case has been discussed and I'm
> not sure what the intended behavior here is.
> >
> > I missed that one. There's a test for var_dump("{$null?->foo}"); but
> > not one without the braces. I would classify this as a bug and expect
> > this to behave the same as -> (but not erroring on null obviously).
> > Worth noting that chaining won't work as it doesn't work for ->
> > either.
> >
> > Sara/Gabriel, What do you think? Should we fix this? I'm assuming this
> > will only require a change in the grammar but I haven't checked yet.
>
> Just as I sent this I realized this is technically a breaking change,
> probably a small one but still worth mentioning. I'm now also not
> totally sure if we should change it at this point. Let me know what
> you think.
>
>
Hah! And just as I sent my previous message, I noticed you started THIS
thread before asking me about it elsewhere. Circles
Anyway, IMO this comes under bugfix. By all means fix it up. :D
-Sara
[PHP-DEV] Null-safe property access in interpolated strings
Do we expect this to work? $foo = new stdClass; $foo->bar = "Hello"; echo "$foo?->bar world\n"; Because at the moment it doesn't: https://3v4l.org/nLv3l -Sara
Re: [PHP-DEV] Re: [VOTE] nullsafe operator RFC
Hi again
> > I just noticed that while we support "$a->b", we do not support "$a?->b"
> > (the quotes are relevant -- I'm talking about interpolated strings here).
> > That is, in the latter case the "?->b" is just treated like a string part,
> > not like a property access.
> >
> > I don't think the behavior for this case has been discussed and I'm not
> > sure what the intended behavior here is.
>
> I missed that one. There's a test for var_dump("{$null?->foo}"); but
> not one without the braces. I would classify this as a bug and expect
> this to behave the same as -> (but not erroring on null obviously).
> Worth noting that chaining won't work as it doesn't work for ->
> either.
>
> Sara/Gabriel, What do you think? Should we fix this? I'm assuming this
> will only require a change in the grammar but I haven't checked yet.
Just as I sent this I realized this is technically a breaking change,
probably a small one but still worth mentioning. I'm now also not
totally sure if we should change it at this point. Let me know what
you think.
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Putting the match expression in constant expressions in PHP 8.0 or 8.1
Hi internals, For unrelated reasons detailed in https://github.com/php/php-src/pull/5951#issuecomment-670969676 , I'm not planning on continuing work on this due to issues I found thinking about the proposal. I initially started work on this because the intended behavior seemed underspecified. "[No objections] from me, though I don't think I'd use it personally." sums up my current stance on that. > Such a construct would be compile-time evaluated, so not having a match > should result in a compile error. Constants in PHP are lazily evaluated under some circumstances, e.g. class constants in constant expressions defer evaluation if they refer to other class constants so that classes aren't unnecessarily autoloaded. https://github.com/php/php-src/pull/5951/files#diff-96ef697f12a482e3f2a7cb0966a6c5beR46 is an example of UnhandledMatchError in function default params, which are also deliberately not permanently cached by C. Compile-time evaluation was something left out of that implementation, but is something that would get added in `zend_const_expr_to_zval`, like it already is for AST_CONDITIONAL. - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] nullsafe operator RFC
Hi Nikita
>> > I started the vote on the nullsafe operator RFC.
>> > https://wiki.php.net/rfc/nullsafe_operator
>
> I just noticed that while we support "$a->b", we do not support "$a?->b" (the
> quotes are relevant -- I'm talking about interpolated strings here). That is,
> in the latter case the "?->b" is just treated like a string part, not like a
> property access.
>
> I don't think the behavior for this case has been discussed and I'm not sure
> what the intended behavior here is.
I missed that one. There's a test for var_dump("{$null?->foo}"); but
not one without the braces. I would classify this as a bug and expect
this to behave the same as -> (but not erroring on null obviously).
Worth noting that chaining won't work as it doesn't work for ->
either.
Sara/Gabriel, What do you think? Should we fix this? I'm assuming this
will only require a change in the grammar but I haven't checked yet.
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] nullsafe operator RFC
On Fri, Jul 31, 2020 at 10:59 AM Ilija Tovilo wrote: > Hi internals > > > I started the vote on the nullsafe operator RFC. > > https://wiki.php.net/rfc/nullsafe_operator > > I'm happy to announce that the RFC was accepted with 56 votes in favor > and 2 votes against. Thanks to everybody who participated! > > Ilija > I just noticed that while we support "$a->b", we do not support "$a?->b" (the quotes are relevant -- I'm talking about interpolated strings here). That is, in the latter case the "?->b" is just treated like a string part, not like a property access. I don't think the behavior for this case has been discussed and I'm not sure what the intended behavior here is. Nikita
Re: [PHP-DEV] Putting the match expression in constant expressions in PHP 8.0 or 8.1
On Sat, Aug 8, 2020 at 2:22 AM tyson andre
wrote:
> Hi internals,
>
> The match expression can be thought of as a much more concise/readable
> equivalent to chained ternary operators.
> I'm proposing allowing matches in constant expressions when all parts of
> the match are constant expressions.
>
> For example, these two class constants would have equivalent behaviors if
> match expressions were allowed in constant expressions.
>
> ```
> class MyClass {
> const CONFIG_SETTING = (APP_ENVIRONMENT == 'dev' || APP_ENVIRONMENT ==
> 'stage') ? 'development-config' :
> (APP_ENVIRONMENT == 'prod' ? 'production-config' : null);
>
> const CONFIG_SETTING = match(APP_ENVIRONMENT) {
> 'dev', 'stage' => 'development-config',
> 'prod' => 'production-config',
> default => null,
> };
> }
> ```
>
> https://github.com/php/php-src/pull/5951 implements the main part of the
> change.
>
Hi, thanks, just noticed that your examples should use `===` not `==`.
Regards
--
Guilliam Xavier
Re: [PHP-DEV] Putting the match expression in constant expressions in PHP 8.0 or 8.1
On Fri, Aug 7, 2020 at 7:22 PM tyson andre wrote: > The match expression can be thought of as a much more concise/readable > equivalent to chained ternary operators. > I'm proposing allowing matches in constant expressions when all parts of > the match are constant expressions. > > That seems pretty reasonable. > 1. Should this target 8.0 or 8.1? I'm leaning towards 8.1 since the beta > is already out. > 8.1, the 8.0 ship has sailed. > 2. Are there objections to doing this? > Not from me, though I don't think I'd use it personally. > 3. Should/shouldn't php enforce that the default arm exists for match *in > constant expressions* >(constant expressions can already throw errors when evaluated for > various reasons, but UnhandledMatchError is new) > Such a construct would be compile-time evaluated, so not having a match should result in a compile error. Having a default should be considered best-practice (to avoid surprise compile failures), but I don't think it needs to be a hard-requirement. -Sara
Re: [PHP-DEV] Re: Proposal: shorthand syntax for initializing arbitrary-precision("bigint") numbers?
On 08/08/2020 13:44, Andrea Faulds wrote:
For example, what if we allowed string prefixes to have special
user-defined meanings, like:
n"123_456" // expands to: gmp_init('123_456')
u"foo bar" // expands to: new UnicodeString("foo bar") (some class I
made up)
d"123.456" // expands to: new Decimal("123.456") (also an imaginary
class)
This would be a similar idea to JavaScript's template string tags:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
That reminds me more of C++'s "user-defined literals";
https://docs.microsoft.com/en-us/cpp/cpp/user-defined-literals-cpp?view=vs-2019
has a decent introduction, and https://stackoverflow.com/q/237804/157957
some discussion of their advantages. As you say, they are basically
sugar around a function call (implemented in C++ as an operator
overload, because that's a hammer they had available).
An interesting advantage in PHP would come if we could limit literals to
be computable at compile-time:
* They could be pre-computed and cached on compilation, saving a
function call.
* They could be used in restricted contexts such as constant definitions
and parameter defaults.
Initially, this would probably mean restricting them to built-in types,
but could potentially be opened up to userland later once some other
pieces were in place (structs feel closely related).
Regardless of the syntax, having a BigNum type constructible at
compile-time would be a big advantage over GMP, especially if it could
be generalised to expressions of multiple BigNums:
const GOOGOL = 10_bignum ** 100; // type of result inferred from one
operand, in the same way that 10*2 !== 10.0*2
const GOOGOLPLEX = 10 ** GOOGOL; // type of result inferred from
existing constant
function waste_time(BigNum $iterations = GOOGOLPLEX) { ... }
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Proposal: shorthand syntax for initializing arbitrary-precision("bigint") numbers?
Hi Andrea,
> > What are your thoughts on making `123_456_000_000_000_000_000_000n` a
> > shorthand for `gmp_init('12345600')` (or a call with
> > equivalent results)
> > (similar to existing backtick string syntax is a shorthand for
> > `shell_exec()`)
>
> We could do that, but maybe this is a good opportunity to do something
> with a wider benefit than GMP by having a generalised solution? GMP is
> already special in some ways and it would be a shame to have even more
> functionality that privileges it.
>
> For example, what if we allowed string prefixes to have special
> user-defined meanings, like:
>
> n"123_456" // expands to: gmp_init('123_456')
> u"foo bar" // expands to: new UnicodeString("foo bar") (some class I
made up)
> d"123.456" // expands to: new Decimal("123.456") (also an imaginary
class)
>
> This would be a similar idea to JavaScript's template string tags:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
>
> How you'd define the mappings from prefixes to executed code, I'm not
> sure, but we could just make it call a function by that name in the
> current namespace… though that would prompt the question “why not just
> write `d("123.456")`, which is already possible?” and I don't have a
> good answer to that :)
I'd feel like the former syntax would be more readable/familiar.
https://en.cppreference.com/w/cpp/language/user_literal also exists. It
supports literals like `2.0_km` or `"one"_w.
`void operator "" _km(long double); // OK, will be called for 1.0_km`
A brand new type of operator function separate from global functions (possibly
with autoloading) would be one possible way to execute that.
That being said, I don't know extending that syntax to user-defined functions
would pass as an RFC, and I don't personally interest in adding it.
- In C++, you'd know if there was a bug at compile time.
The C++ compiler would tell you that the program could not contain `1.0_km +
1.0_Litres` or `1.0_km + 2` before the program could run.
- Maybe this could be initially limited to C extensions (PECLs) during
initialization?
The ability to perform operations on user-defined classes is limited because
https://wiki.php.net/rfc/userspace_operator_overloading didn't pass.
- User-defined operators would also enable code like `$x =
download_url"https://";`, which may cause confusion reviewing code but
should hopefully be rare in practice.
- If somebody ended up adding user-defined literal syntaxes, I'd really hope
that those would be separate from global function symbols and unambiguously
resolved (e.g. by not having namespaces, or by requiring that the operator be
explicitly imported to be used)
- Different frameworks may end up with conflicting definitions of the same
operator for short operators.
- Also, there'd be no indication if there were typos such as `$a = yeeld"END";`
and I'm not sure how lexing would work with prefixes. Suffixes may work, I'm
not sure.
Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Proposal: shorthand syntax for initializing arbitrary-precision("bigint") numbers?
Hi Tyson,
tyson andre wrote:
What are your thoughts on making `123_456_000_000_000_000_000_000n` a shorthand
for `gmp_init('12345600')` (or a call with equivalent results)
(similar to existing backtick string syntax is a shorthand for `shell_exec()`)
We could do that, but maybe this is a good opportunity to do something
with a wider benefit than GMP by having a generalised solution? GMP is
already special in some ways and it would be a shame to have even more
functionality that privileges it.
For example, what if we allowed string prefixes to have special
user-defined meanings, like:
n"123_456" // expands to: gmp_init('123_456')
u"foo bar" // expands to: new UnicodeString("foo bar") (some class I
made up)
d"123.456" // expands to: new Decimal("123.456") (also an imaginary
class)
This would be a similar idea to JavaScript's template string tags:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
How you'd define the mappings from prefixes to executed code, I'm not
sure, but we could just make it call a function by that name in the
current namespace… though that would prompt the question “why not just
write `d("123.456")`, which is already possible?” and I don't have a
good answer to that :)
Regards,
Andrea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
> > > This is some new complexity, even if only a small amount right now. > My question remains about how much more added complexity it will > require later if we implement extensions like nested attributes. > What? Are you actually saying that 30 lines of code add "complexity"? I think you should look more at the PHP source code before going to these nonsensical conclusions. PHP is a fully fledged language, not a "let's write the shortest code possible" competition. As for the nested attributes, you can implement those with simple recursion. You are trying to create problems here that don't exist. > Yes, PHP has historically been rather verbose in some ways. > Thankfully this has been gradually changing, with the short array > syntax added in 5.4, and more recently short arrow functions, > constructor property promotion, and the match expression having an > explicit goal to reduce verbosity. > No offense intended but saying that 1 extra character somehow adds verbosity is quite honestly, one of the stupidest things I have heard. While we at it, let's also rename other keywords: `function` to `f`, `while` to `w` and `static` to `s`. You know, to save those few extra characters. > What is the goal of the grouped attribute construct? I still haven't > received an answer about what makes it better than `@@`. > You can't compare attribute syntax against attribute feature. You better tell me why `@@` is better than `@[]` using arguments and not with "boo, I have to type 1 extra character with `@[]`". As for the grouped attributes. Why do we allow grouped properties and class constants? It's alternative code style that some might prefer. > > Aren't docblock annotations only wrapped in /** */ because they have to > be inside a comment? There is no need for this with the native > attribute syntax. To me, the `#[]` and `@[]` tokens don't at all look > similar to docblock comment boundaries, anyway. > Even more so with `@@`, which look nothing alike to docblocks. Just because docblock annotations contain the same character as attribute syntax, it doesn't magically mean "it's like docblocks". Because if so, `@[]` looks far far more like docblocks than `@@`. > Best regards, > Theodore Best regards, Benas
