Proposal: AS assertions

On Thu, Mar 21, 2024 at 11:06 PM Rowan Tommins [IMSoP]
imsop.php@rwec.co.uk wrote:

I suppose we are taking this from different viewpoints, yours appears
to be more of a philosophical one, whereas mine is more of a practical
one.

My main concern is consistency; which is partly philosophical, but does have practical impact - the same syntax meaning the same thing in different contexts leads to less user confusion and fewer bugs.

But I also think there are real use cases for "error on anything other than either Foo or null" separate from "give me a null for anything other than Foo".

I can't think of any example of this. In every case I've ever written
a manual typecheck, I've done something differently from null vs. the
actual type I'm checking for. In only a few instances were they ever
the same. I'd be happy to research this by looking at some older code
that has to do manual typechecks; but I have a feeling if you were to
make Foo|null only throw, it would be pointless as most people would
end up writing this anyway, making the |null completely superfluous:

if $x === null {
/* do something for null */
}
$y = $x as Foo;

$x = $a as null;

(or any other value, such as true|false) appears to have no practical
purpose in this particular case.

There's plenty of possible pieces of code that have no practical purpose, but that on its own isn't a good reason to make them do something different.

"null" as a standalone type (rather than part of a union) is pretty much always pointless, and was forbidden until PHP 8.2. It's now allowed, partly because there are scenarios involving inheritance where it does actually make sense (e.g. narrowing a return type from Foo|null to null); and probably also because it's easier to allow it than forbid it.

That's not really what we're talking about anyway, though; we're talking about nullable types, or null in a union type, which are much more frequently used.

I think that is where we are getting confused: null is a value (or
at least, the absence of a value). The fact that the type system
allows it to be used as though its a type (along with true and false)
is interesting, but I think it is confusing the conversation. It might
be worth defining the meaning of "type" and "value" as well defining
what the "as" means in each context. Is it the same? Is it different?
I think this is worth spending some time on, but I have a feeling
there'll be bigger discussion about that when pattern matching shows
up.

Further, reading "$x =
$a as null", as a native English speaker, appears to be the same as
"$x = null".

Well, that's a potential problem with the choice of syntax: "$x = $a as int" could easily be mistaken for "cast $a as int", rather than "assert that $a is int".

If you spell out "assert that $a is null", or "assert that $a is int|null", it becomes very surprising for 'hello' to do anything other than fail the assertion.

$a as int is quite different from $a as null. One is a bonafide type,
the other is a value. I don't think you can mistake this and they are
very different semantics.

As I mentioned in the beginning, I see this mostly being used when
dealing with mixed types from built-in/library functions, where you
have no idea what the actual type is, but when you write the code, you
have a reasonable expectation of a set of types and you want to throw
if it is unexpected.

My argument is that you might have a set of expected types which includes null, and want to throw for other, unexpected, values. If "|null" is special-cased to mean "default to null", there's no way to do that.

I'm arguing that that doesn't make any sense; this isn't a
method/function signature. I invite you to try writing some fictional
code using both semantics. I'm being sincere when I say I'd love to
see an example that would use |null on the right hand side of "as" and
want to throw.

Right now, the best way to do that is to simply
set a function signature and pass the mixed type to the function to
have the engine do it for you

And if you do that, then a value of 'hello' passed to a parameter of type int|null, will throw a TypeError, not give you a null.

As I illustrated in my last e-mail, you can even (since PHP 8.2) have a parameter of type null, and get a TypeError for any other value. That may not be useful, but it's entirely logical.

Ah, yeah, I guess I could have been more clear. This is what I find
myself writing quite a lot of lately (unfortunately):

foreach ($listOfMyAttributes as $attributeReflection) {
$instance = $attributeReflection->newInstance();
assert($instance instanceof MyAttribute);
$instance->someMethod();
}

as well as:

$value = genericFuncReturnsMixed();
if ($value === null) {
/* handle null */
}
if($value instanceof MyType) {
$value->doSomething();
} else if ($value instanceof MyOtherType) {
$value->doSomethingDifferent();
}

This would be better written as

foreach ($listOfMyAttributes as $attributeReflection) {
$instance = $attributeReflection->newInstance() as MyAttribute;
}

or

$value = genericFuncReturnsMixed();
if ($value === null) {
/* handle null */
}
($value as MyType|null)?->doSomething();
($value as MyOtherType|null)?->doSomethingDifferent();

Not having an "escape hatch" would mean writing something like:

$value = genericFuncReturnsMixed();
if ($value === null) {
/* handle null */
}
try {
($value as MyType)->doSomething();
} catch {
}

try {
($value as MyOtherType|null)->doSomethingDifferent();
} catch {
}

which will probably trip up a bunch of lint rules for having an empty
catch ... but that is beside the point.

It makes more sense, from a practical programming
point-of-view, to simply return the value given if none of the types
match.

This perhaps is a key part of our difference: when I see "int|bool|null", I don't see any "value given", just three built-in types: int, which has a range of values from PHP_INT_MIN to PHP_INT_MAX; bool, which has two possible values "true" and "false"; and null, which has a single possible value "null".

So there are 2**64 + 2 + 1 possible values that meet the constraint, and nothing to specify that one of those is my preferred default if given something unexpected.

I agree this is the key point, and goes back to what I was saying
about null not actually being a type, but a value. If any value could
be a type, I think I would feel differently, but I'd still argue that
null should be a special case for the nice syntax you get from that.

Regards,

--
Rowan Tommins
[IMSoP]

$optionalExpiryDateTime = $expiry as ?DateTimeInterface else new DateTimeImmutable($expiry);
I'm not sure I can grok what this does...

$optionalExpiryDateTime = ($expiry === null || $expiry instanceof
DateTimeInterface) ? $expiry : new DateTimeImmutable($expiry)

Trying to write it as a one-liner is going to make for ugly code - that's why I'd love to have a new way to write it! But yes, that's the right logic.

With the "is" operator from the Pattern Matching draft, it would be:

$optionalExpiryDateTime = ($expiry is ?DateTimeInterface) ? $expiry : new DateTimeImmutable($expiry);

But with a clearer assertion that the variable will end up with the right type in all cases:

$optionalExpiryDateTime = $expiry as ?DateTimeInterface else some_other_function($expiry);
assert($optionalExpiryDateTime is ?DateTimeInterface); // cannot fail, already asserted by the "as"

Maybe? What would be the usefulness of this in real life code? I've
never written anything like it in my life.

I already explained the scenario: the parameter is optional, so you want to preserve nulls; but if it is present, you want to make sure it's the correct type before proceeding. Another example:

// some library function that only supports strings and nulls
function bar(?string $name) {
if ( $string !== null ) ...
else ...
}
// a function you're writing that supports various alternative formats
function foo(string|Stringable|int|null $name = null) {
// we don't want to do anything special with nulls here, just pass them along
// but we do want to convert other types to string, so that bar() doesn't reject them
bar($name as ?string else (string)$name);
}

To put it another way, it's no different from any other union type: at some point, you will probably want to handle the different types separately, but at this point in the program, either type is fine. In this case, the types that are fine are DateTimeInterface and null; or in the example above, string and null.

$optionalExpiryDateTime = $expiry == null ? $expiry : $expiry as
DateTimeInterface ?? new DateTimeImmutable($expiry as string ?? "now")

If you think that's "readable" then we might as well end the conversation here. If that was presented to me in a code review, I'd probably just write "WTF?!"

I have no idea looking at that what type I can assume for $optionalExpiryDateTime after that line, which was surely the whole point of using "as" in the first place?

Regards,

Rowan Tommins
[IMSoP]