Permalink
Reply
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(...);
...
