@glaebhoerl Does Haskell allow pattern synonyms to be used as variables?
Anyways, given the following pattern, Some(<>)
and assuming Some
is the enum variant of Option
, whatever replaces <>
in the code can be interpreted in two ways:
- It can be a previously defined value, in which case
PartialEq
is used to determine it’s value, at least if it’s a primitive type (my previous code demonstrates this). - It can introduce a new binding which will refer to the value inside the
Some
, if it matches.
If const
introduces a value, then it should consistently behave that way, meaning, the behavior of primitive types today. If const
actually did introduce a pattern synonym, then it would have to allow for the second case above as well, meaning I could do something like this:
const C: Option<(usize, usize)> = Some(1, x);
let a = match Some((1, 2)) {
C => x,
_ => 0,
}
But, this doesn’t work and if it did, C couldn’t be used as a variable. And it would have the subjectively unfortunate side effect that x
would be introduced without any way to know at the point of the pattern match itself.
Overall, the goal of allowing extensible values within patterns seems valuable, since it allows user defined types to achieve the same syntax and semantics that primitive types enjoy today.
Unfortunately, I don’t see any benefits of allowing const
which declares values (as opposed to pattern synonyms) to act like a structural match rather than a value match, when the behavior would be restricted when compared to what I’d want from pattern synonyms while also causing an inconsistency when compared to primitive types.
That said, pattern synonyms do sound interesting and perhaps they deserve their own place in the language?