> > 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 > null. 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 types. Ben
