Hi! Hey Larry, > > 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. > > I've heard a few times that this would reduce type safety. Well, on runtime it really does, the same way when you use null in a wrong manner, but with static analysis tools in place I wouldn't expect a formal proof that it's impossible to analyze that kind of code. Unless we are eval'ing or declaring variables dynamically... I'll try to research a bit on that.
What would be the default static analyser used for PHP today? Psalm? Ty, Márcio
