Re: [RFC] [DISCUSSION] Scalar Pseudo-type

Am 26.12.2017 um 19:18 schrieb Larry Garfield:

On Tuesday, December 26, 2017 9:56:21 AM CST Sebastian Bergmann wrote:

Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net:

would you mind to explain this?

"Foo|Bar", "array|string", etc. (still) make no sense to me. "scalar" makes sense to me although it is but an alias for "bool|float|int|string".

If I may, I think the argument has always been that 1) Foo & Bar makes total sense 2) int|float makes total sense 3) int & string is illogical so wouldn't matter anyway

not true function x(int|string $x) { $x = (int)$x; } $x can be simply from a database simply because without MYSQLI_OPT_INT_AND_FLOAT_NATIVE which is sadly not default you get everything back as string and so you can place the casting in the function instead of every single caller in strict_types mode while you don#t accept object, array or boolean here why not cast a boolean here? in case of the result of strpos() in the caller is false it likely should not call the function anyways but handle that error itself

4) Foo|Bar rarely makes sense but may sometimes, and its legality is an acceptable trade-off to get the first two. In previous discussions it always seemed that people fixated on case 4 and ignored the usefulness of cases 1 and 2

as this is a programming language it's up to the user who writes the code in the language what is useful for his case - so if one is fixated on 3 or 4 because they would become possible the argumentation is strange anyways and "etc. (still) make no sense to me" is a personal opinion which hardly justifies a downvote at all unless there are real technical reasons in my total valid usecase of 3) above in strict_types mode i must ommit the typehint at all or modify every single caller and that alone would justify unions