Option types and pattern matching.

[Jacob Carlborg via Digitalmars-d]

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