Like you could totally make an overload that lets you do ???("whoopsies") but a non-Scala-er is going to be pretty confused by that (not that languages should be designed to accommodate people who don't know them, but ??? doesn't seem to have any advantages over TODO either)
@EldritchConundrum If I'm understanding this right, Scala has it too (unapply), also a fairly obscure feature there. Although I don't think exhaustivity checking works too well with Scala's unapply
Oh never mind I misunderstood
Okay looks like they're similar but F#'s active patterns work well with exhaustivity checking?
@user i think active patterns implicitly create an enum
I think equivalent scala code is something like
object Even:
def unapply(x: Int): Option[Unit] = if x % 2 == 0 then Some(()) else None
object Odd:
def unapply(x: Int): Option[Unit] = if x % 2 != 0 then Some(()) else None
2 match
case Even(_) => "even"
case Odd(_) => "odd"
I don't think you can make parameterless cases because those turn into equality checking and not unapplying
@RubenVerg Can't you make unapply return a boolean for that?
@RubenVerg Ah that's a simpler way of thinking about it. That must be convenient, I've had to unnecessarily use case _ => in Scala sometimes because the compiler doesn't understand that my matches really are exhaustive
@UnrelatedString Which one, letting you define case Even yourself in Scala, or making it so you can tell the compiler that case Even and case Odd cover all of Int (there's a proposal for the latter sitting somewhere)?
Well case Even is, as Madeline pointed out, used to compare equality to some singleton object Even, and case even is used to mean "whatever it is, bind it to a new variable even"
I keep wanting to use F# but it seems like Scala in that it's an awesome language bolted on top of a very different (not necessarily bad) platform. Except F# seems even more different from C# and the like than Scala is from Java
It seemed like they shoved classes and subclassing (based on names rather than structure) into an ML and it's really messed with type inference and whatnot. Is that understanding right?
@user understanding F# is simple if you already understand both ocaml and C#. (this is both a compliment and severe criticism)
in F# there are two ways of doing everything, and it's honestly annoying. But, I'm using it to play with syntax trees, and active patterns are perfect for that.
I don't have a lot of type inference problems with it, other than the incomprehensible errors that result from underuse of type annotations that is usual with HM inference. but that's technically my fault
Someone who knows well C# and Visual Studio will notice weaknesses in the IDE support of F#. It's not bad at all, it's just not as good as the best in class (languages that were directly designed for/with an associated IDE).
I've recently had issues with the C# LSP, with features like "jump to definition" not working across files (and semantic highlighting breaking as a result of not finding things).
It's a good thing that LSP exists, but last time I looked at what it could do in VS Code, it's clear how far it is from true IDE integration like in VS non-Code.
