Could be handy to allow this in normal functions too (but this it not
the main use case and could be disallowed):
public static function get(string $name, mixed $default = uninitialized): string
{
$value = getenv($name);
if ($value === false) {
return $default; // throws uninitiali
On Tue, Jun 3, 2025, at 4:33 AM, Christoph M. Becker wrote:
> On 03.06.2025 at 03:36, Anton Smirnov wrote:
>
>> On 02/06/2025 20:01, Larry Garfield wrote:
>>
>>> The result of this RFC is that the following would no longer be an
>>> error, yes?
>>>
>>> function test(): void {
>>> print "test";
>
On Mon, Jun 2, 2025 at 10:40 PM Larry Garfield
wrote:
> On Mon, Jun 2, 2025, at 3:28 PM, Rowan Tommins [IMSoP] wrote:
> > On 02/06/2025 17:57, Larry Garfield wrote:
> >> Well, now you're talking about something with a totally separate
> compile step, which is not what Michael seemed to be describ
On 03/06/2025 18:20, Gina P. Banyard wrote:
On Tuesday, 3 June 2025 at 02:36, Anton Smirnov wrote:
On 02/06/2025 23:50, Rowan Tommins [IMSoP] wrote:
I agree the type hierarchy you describe is weird, but rather than
throwing away the functionality completely, I wonder if we can make it
more c
On 02/06/2025 19:11, Gina P. Banyard wrote:
Hello internals,
This is the first RFC out of a set of type system related RFCs I want to
propose for PHP 8.5.
It also used the recently enabled Markdown support on the wiki, so there might
be a few oddities.
The RFC proposes to deprecate implicit t
On Tue, Jun 3, 2025, at 18:19, Gina P. Banyard wrote:
> On Monday, 2 June 2025 at 22:05, Rob Landers wrote:
>> No offense, but this feels like it was written by someone who doesn’t use
>> non-strict mode very often.
>
> As yes, saying this to me, someone that is known to have said on stage,
>
I've changed the structure, followed the rfc template now.
The voting section isn't available now, because the RFC is under discussion.
On Tue, May 27, 2025 at 10:58 PM Dmitry Derepko wrote:
> Thanks Tim for the answer.
>
> Your replies went to the Spam folder. I don't know why.
>
> I'll change
On Mon, Jun 2, 2025, at 11:34 PM, Nick wrote:
> I would like to add, personally, I don’t believe the above is dumb:
>
> ```php
> class Dumb {
> public readonly int $value { get => $this->value * random_int(1, 100); }
> }
> ```
>
> I think it is a legitimate use-case.
> Why wouldn’t a `readonly` pr
On Mon, Jun 2, 2025, at 4:02 PM, Rob Landers wrote:
> The rules around coercion are pretty
> simple and well documented.
Just to note, however simple or not simple they are in 8.4, they are
substantially simpler and more logical in 8.4 than they were in 7.0 when strict
typing was introduced.
On Monday, 2 June 2025 at 22:05, Rob Landers wrote:
> No offense, but this feels like it was written by someone who doesn’t use
> non-strict mode very often.
As yes, saying this to me, someone that is known to have said on stage,
multiple times, during talks that
> The strict_types declare was
On Tuesday, 3 June 2025 at 16:18, Tim Düsterhus wrote:
> Am 2025-06-03 01:46, schrieb Ilija Tovilo:
>
> > IMO, these checks are useful enough not to be removed.
>
> I agree with Ilija (and also Rowan).
Well, I'm not sure Ilija and Rowan agree between each other.
AFAIU Ilija thinks void living o
On Tue, Jun 3, 2025, at 2:59 AM, Dmitry Derepko wrote:
>>
>> Pipe and compose are importantly different operations. I've had user-space
>> implementations of both available for years in crell/fp:
>> https://github.com/Crell/fp/blob/master/src/composition.php
>> I'd love to have a compose opera
On Tuesday, 3 June 2025 at 02:36, Anton Smirnov wrote:
> On 02/06/2025 23:50, Rowan Tommins [IMSoP] wrote:
>
> > I agree the type hierarchy you describe is weird, but rather than
> > throwing away the functionality completely, I wonder if we can make it
> > more consistent:
> >
> > - Make "no r
Hi
Am 2025-06-03 01:46, schrieb Ilija Tovilo:
IMO, these checks are useful enough not to be removed.
I agree with Ilija (and also Rowan). To me there is an important
semantic difference between “not returning anything” and “always
returning null”. I believe that `void` being in a distinct ty
On Monday, 2 June 2025 at 21:53, Rowan Tommins [IMSoP]
wrote:
> On 02/06/2025 17:27, Gina P. Banyard wrote:
>
>> The objective is to fix a weird quirk of PHP's type system, where void lives
>> in its own type hierarchy.
>> This is visible mainly in that a lack of return type is not isomorphic t
On Monday, 2 June 2025 at 18:08, Kamil Tekiela wrote:
> The RFC mentions that this will now become valid:
>
> function foo(): void {
> return null;
> }
>
> But what about the opposite:
>
> function foo(): null {
> return;
> }
This would also work indeed.
> or what Larry was trying to suggest
Hi Volker,
Sorry for the delay in answering, it's been a long week-end AFK on my side.
Le mer. 28 mai 2025 à 16:52, Volker Dusch a
écrit :
> Hi Nicolas,
>
> Thank you for the great email and for thinking this through. Getting input
> from the folks that maybe will use this feature the most is v
On Tue, June 3, 2025 at 04:29 Christoph M. Becker wrote:
> On 02.06.2025 at 18:11, G. P. Banyard wrote:
>
>> The RFC proposes to deprecate implicit type coercions to and from the bool
>> type
>> for other scalar types. This a "weak" mode change only, as when strict_types
>> are
>> enabled none of
On 03.06.2025 at 03:36, Anton Smirnov wrote:
> On 02/06/2025 20:01, Larry Garfield wrote:
>
>> The result of this RFC is that the following would no longer be an
>> error, yes?
>>
>> function test(): void {
>> print "test";
>> }
>>
>> // This currently gives an error, but you propose that it
>>
On 02.06.2025 at 18:11, Gina P. Banyard wrote:
> The RFC proposes to deprecate implicit type coercions to and from the bool
> type for other scalar types.
> This a "weak" mode change only, as when strict_types are enabled none of
> these coercions can happen.
>
> Let me know what you think abou
>
>
> Pipe and compose are importantly different operations. I've had
> user-space implementations of both available for years in crell/fp:
> https://github.com/Crell/fp/blob/master/src/composition.php
> I'd love to have a compose operator natively in PHP, too. The RFC for
> that is already wri
On Mon, Jun 2, 2025, at 3:28 PM, Rowan Tommins [IMSoP] wrote:
> On 02/06/2025 17:57, Larry Garfield wrote:
>> Well, now you're talking about something with a totally separate compile
>> step, which is not what Michael seemed to be describing at all. But it
>> seems like that would be necessary.
22 matches
Mail list logo
