On Wed, Jul 15, 2020, at 11:43 AM, Marco Pivetta wrote: > Hey Larry, > > On Wed, Jul 15, 2020 at 5:32 PM Larry Garfield <la...@garfieldtech.com> > wrote: > > > 1) return null, which is a non-type, and thus you need to make the return > > type ?User or User|null, which means the caller *must* always check it's > > nullness. > > > > Allowing an object to falsify itself is a 4th, more type-safe option. It > > lets you return an object that both fails a boolean check (like null) but > > also has default values in it for the base case. A user object likely > > wouldn't use that, but a value object like an Address very well could. > > > > Until we can support for-reals monads (which would require enums and > > generics to do properly; the former is possible the latter is very hard), > > it's the best option we have for more type-safe returns. > > > > Adding a "falsey" state for code that expects `is_object($foo) === (bool) > $foo` seems to be a massive BC break to me, and reduces type safety of > boolean operators (and checks) by expanding the `object` type and all > operators and expressions that can interact with it. > > In general, `?T` is very much equivalent to `Maybe T`
I disagree entirely. The value of a Maybe over just null is 1) You can bind to it even if the result is empty; the "if is null" check gets abstracted away from the main code. 2) You are forced to unwrap/extract the value if you're not just binding, which makes it less likely you'll forget to check if it's null. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
