Add fallback value syntax for ini variables

[Misterio77]

Hi, all!

This PR implements fallback/default values when substituting variables on ini files, like: ${VAR:-fallback}. I was actually surprised this wasn't implemented yet, as it's a very useful feature.

I know a thing or two about lexers/parsers, but it's not something I'm super familiar with, so let me know if there's any way this can be improved!

At the moment, the fallback value is treated similarly to a raw string, so it does not support arbitrary expressions (such as nested variables), I couldn't get it to without adding state pushes and pops everywhere on the lexer. It works similarly to offsets/sections now, and supports nesting!

As I understand, this should go through the RFC process? If so, I'm totally okay with writing one :). Let me know if there's any etiquette I might have missed, too.

---

As an example, my usecase is using environment variables to configure php-fpm, while also having some sane defaults. Like so:

error_log = syslog
daemonize = false

[www]
listen = localhost:${DRUPAL_FPM_PORT:-9000}

[iluuu1994]

@Misterio77 Thank you for your PR! You might get away with just a mail to the mailing list, if nobody objects to the change. If there are discussions on semantics or the usefulness then an RFC is definitely in order.

[Misterio77]

I redid this and now fallback is a var_string_list instead of a TC_RAW. That means the fallback value behaves similarly to a offset value.

You can do some cool stuff such as nesting:

host = ${HOSTNAME:-localhost:${PORT:-8080}}

If you're using the typed parser, numbers become numbers, as expected:

foo = ${undefined_variable:-12345}
bar = 12345

Both are "int(12345)"

For now, the separator is !, I'd like to make it be :-, but it's a little hard. I'll mark this PR as draft while I work on it. Thanks to @iluuu1994, :- works now.

[iluuu1994]

@Misterio77 I pushed the changes for making :- work, I hope that's ok. Feel free to adjust as you feel appropriate. The next step would be to discuss this change on the mailing list.

[Misterio77]

Thanks a lot for helping out, @iluuu1994! I will send an email to the list shortly

[derickr]

Did you announce this on the ML? I wasn't aware of this... and spend some time on #11661 which is a much simpler solution (I guess, with some different drawbacks).

[derickr]

Sent an email myself now: https://news-web.php.net/php.internals/120805

[Misterio77]

Hey @derickr,

Life got in the way and I couldn't quite muster the energy to write the email. Thanks a lot for sending it! :)

[brzuchal]

Would it make sense to improve php.ini-production and php.ini-development for most/all distributed settings by default?
Meaning entries like this:

; Maximum amount of memory a script may consume
; https://php.net/memory-limit
memory_limit = 128M

Would be extended with env var clause and default to default values, like:

; Maximum amount of memory a script may consume
; https://php.net/memory-limit
memory_limit = ${PHP_MEMORY_LIMIT:-128M}

[Misterio77]

Hey @brzuchal, I think it does make sense! Maybe as a separate PR after we merge this one?