April 10, 2019 09:email@example.com (Benjamin Morel)
> I'm somewhat split on this one.
> On the one hand, if I make an explicit cast, my intention is clear, make
> the best attempt to convert this string into a number. Trimming
> whitespace would be a natural consequence of that.
> On the other hand, I'm a stickler for consistency.
> On the balance of things, I would most certainly like to see leading and
> trailing whitespace render a string ineligible to be implicitly
> converted, but I'd be satisfied with (int)" 123 " converting without error.
I'm all for consistency between `(int)` casting, `(int $x)` function
parameter and `: int` return type, *even* if this justifies allowing
leading and trailing whitespace around numbers, if this helps adoption.
As long as we no longer allow `(int) "abc"` to return `0`, I'm game.
On the topic of errorsfor explicit casts I'd be more inclined to also
> introduce (?int) and in the event the value cannot be converted, return
If (?int) casting is introduced, I would only return null if the original
value is null. Otherwise, throw an TypeError.
This is the only consistent behaviour with scalar type hints and return