> On Jul 23, 2024, at 12:26 PM, Larry Garfield <la...@garfieldtech.com> 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
