There are two distinct ways to pattern match, by type and by value; see templates headers and "template type specialization" and "template value specialization" for the compile time equivalents already in d.

I see no evidence or upgrade path of value pattern matching in rikkis proposal and walters sumtype dip doesn't have any details. While I believe value pattern matching is more useful for imperative code, which, this may be conversational, d still fairly imperative.

I think d should do this, as most of the value is in bools: https://forum.dlang.org/thread/fsjfcairmfcdwraxabdk@forum.dlang.org

but if you need a big ask like redesigning the type system to get started on pattern matching to provide something, well...

see this for example reference: https://www.youtube.com/watch?v=fid014AAf0g

switch(x,y){
  case x=0 ..20: return 30;
  case x=40..60,y=40..80: return 50;
  case x=60..80,y=40..80: return 80;
  case x=60..100: return 30;
  default: return 0;
}

(note I understand theres better solution because toy problems should avoid deeply entangled messes, the real world is less kind; what if the 80 was 100)

You could also get some of the value of type pattern matching with value pattern matching

void foo(nullable!int a,nullable!int b){
  switch(a.isnull,b.isnull,a.forceget,b.forceget){
    case a.isnull: throw(...);
    case b.isnull: throw(...);
    ...