> On Jul 23, 2024, at 12:26 PM, Larry Garfield <[email protected]> wrote:
>
> Hypothetical pattern matching example:
>
> $foo is ['a' => int, 'b' => $b, 'c' => mixed];
>
> That would assert that there's 3 keys. "a" may be any integer (but only an
> integer), "b" can be anything and will be captured to a variable, and "c" must
> be defined but we don't care what it is.
>
> The suggestion is to basically alias _ to "mixed" for pattern purposes:
>
> $foo is ['a' => int, 'b' => $b, 'c' => _];
>
> As "there's a var here but I don't care what it is, ignore it" is a common
> meaning of _ in other languages. But that would need to be disambiguated from a pattern saying
> "c must be an instance of the class _". Technically any symbol/set of symbols could be
> used there (as it's just an alias to mixed, which has the exact same effect), but _ is a common
> choice in other languages.
I do not see this use-case as compelling.
mixed is perfectly sufficient and using _ for a data types just gives two
ways to do the same. Not that multiple ways to do the same thing is necessarily wrong, but I think
it needs a better justification than just to save characters. Besides, it has the potential to
confuse people as to its exact meaning whereas mixed does not.
OTOH, if you really want to say characters — albeit not as many — then choose any,
which is certainly less likely to be confusing and has an analog in Go, TypeScript, and Python, at
least.
Also, AFAIK, few (no?) other languages actually allow for using _ for types, they only
allow using them for variables. I know that to be the case for Go, and if I understand the docs
correctly it is also true for Rust, Zig, Haskell and Swift, with caveats for Rust.
- Rust allows underscore for type inference, e.g.: let x: _ = "Hello, world!";
- Also for a Generics' type placeholder, e.g.: let vec: Vec<_> = vec![1, 2, 3];
- But as for Rust pattern matching, the underscore is only used for values, not types.
For any other languages, I cannot say.
> In theory, that could be expanded in the future to something like (note: this hasn't been
> seriously discussed that I know of, I'm just spitballing randomly):
>
> [$a, $b, _] = explode(':', 'foo:bar:baz');
This is actually where a "blank" variable represented by _ actually makes a
lot of sense. It is also how Go and Zig use them and effectively also how Rust, Haskell, and Swift
use them.
Unlike for types where we have mixed, there is no current globally consistent alternate
to using a blank variable in PHP. The only option is to use an arbitrary name that other developers
won't know the intention of unless the developer adds comments to the effect.
In summary, although I don't have strong feelings about deprecating classes named
_, I do not think the arguments made for disallowing them actually have any analog in
any other languages so I question if there is valid justification for the deprecation. #jmtcw #fwiw
-Mike