On 2015-10-25 06:01, Nerve wrote:
Hello D community! First time poster, I'm utterly fascinated with this language's mix of features. It's powerful and expressive.There are just two conveniences I'd like to see out of D. The first is pattern matching, a functional construct which can unwrap tuples or other containers, usually evaluates to a value (in most languages), and which almost always idiomatically enforces the programmer to match over every possible case of a given type. While ML-inspired languages like F# and OCaml have some good pattern matching syntax, it's not syntax which would fit in to D; I suggest taking inspiration of Rusts's matching construct. match x { Some(7) => "Lucky number 7!", Some(_) => "No lucky number.", None => "No value found" } From that bit of code, we can see another feature at work: The Option type. It wraps another type (i.e. Option int, Option Car) and represents a wrapped presence of a value of that type (Some(n), Some(aCar)) or an absence of that type (None). Combined with pattern matching, we end up with a safe, functional construct which can replace a switch statement in most cases, returns a value, is incredibly compact and readable, and can be used with Options to ensure that we always account for the possibility of a value not present, eliminating a whole class of errors when we use it judiciously. My only concern is that switch statements, while horrendous syntactically, are extremely performant and essentially compile to a series of branches. Are there any counter-arguments for the implementation of these two features? Is D in a state where language additions have come to a stop?
Both of these can be implemented in library code. Although the syntax won't be as nice.
I wouldn't mind having pattern matching as a language feature. -- /Jacob Carlborg
