[RFC] Pre-vote notice for Nullable Types

This RFC has one primary vote and one secondary vote. The primary vote
determines whether we want to add nullable types to our type system. The
secondary vote decides how precisely this will happen, in this instance
deciding whether nullable types will be restricted to return types only
or not. This is a standard voting layout, with precedent in a number of
other RFCs.

The reason why the second vote must use a 1/2 majority is symmetry. You,
as somebody who does not like nullable parameter types, argue from a
perspective of one 2/3 majority RFC for introducing nullable returns and
another 2/3 majority RFC for introducing nullable params. I, as somebody
who thinks supporting this syntax only for returns is wildly
inconsistent, will argue from a perspective of a 2/3 majority RFC for
introducing nullable types and another 2/3 majority RFC for restricting
them to return types only. Depending on the perspective this would
require either a 2/3 majority, or a 1/3 "majority" for unrestricted
nullable types. Using a 1/2 majority vote ensures that there is no bias
for either choice.

The explanation is very clear. Thank you.

Tom

(Btw, I don't disagree about the inconsistency you mentioned. But I don't
think it's a wild inconsistency, rather a justified one, given our
context.)

At this point in time, with the current state of our type system, I agree
that this is not a wild inconsistency.

However, the type system is expanding. Typed properties are already under
discussion, and they would certainly support nullable types (in fact, the
proposal is currently blocked by us not having them yet). Generics are also
already under discussion (though far removed from a viable implementation).
They would, presumably, also support nullable types as generic type
parameters (or at least I don't see why not). Following this trend, we'd
end up in a situation where nullable types are supported everywhere --
apart from parameters.

Which is in my eyes a pretty bad spot to be in. At that point we'd have
gone from this being a "nullable return types" feature to a "nullable
types, but not allowed in parameters" feature, which is just weird.

Example for nullable types used in all of return types, parameter types and
property types.

class Node {
private ?Node $left;
private ?Node $right;
private $value;
public function __construct(?Node $left, ?Node $right, $value) {
$this->left = $left;
$this->right = $right;
$this->value = $value;
}
public function getLeft() : ?Node {
return $this->left;
}
public function getRight() : ?Node {
return $this->right;
}
public function setLeft(?Node $node) {
$this->left = $node;
}
public function setRight(?Node $node) {
$this->right = $node;
}
// ...
}

Not having nullable types in parameters here would require you to either
drop the type altogether, or allow $node->setLeft() (eeeek), or
differentiate between $node->setLeft($nonNullNode) and $node->unsetLeft(),
which tends to be ugly for use in algorithmic transformations.

Regards,
Nikita