On 10/20/2016 10:16 PM, Chris M. wrote:
> So I know you can do some pattern matching with templates in D, but has
> there been any discussion about implementing it as a language feature,
> maybe something similar to Rust's match keyword
> (https://doc.rust-lang.org/stable/book/patterns.html)? What would your
> guys' thoughts be?
>

What I've been really wanting for a long time is the one-two combo of Nemerle's variants and pattern matching:

https://github.com/rsdn/nemerle/wiki/Grok-Variants-and-matching

On Friday, 21 October 2016 at 19:00:55 UTC, Nick Sabalausky wrote:
> On 10/20/2016 10:16 PM, Chris M. wrote:
>> So I know you can do some pattern matching with templates in D, but has
>> there been any discussion about implementing it as a language feature,
>> maybe something similar to Rust's match keyword
>> (https://doc.rust-lang.org/stable/book/patterns.html)? What would your
>> guys' thoughts be?
>>
>
> What I've been really wanting for a long time is the one-two combo of Nemerle's variants and pattern matching:
>
> https://github.com/rsdn/nemerle/wiki/Grok-Variants-and-matching

There is std.variant, though I haven't used it much myself and don't know how well it compares. Seems like that library would provide a good basis for providing pattern matching though.

On 10/23/2016 03:38 PM, Chris M wrote:
> On Friday, 21 October 2016 at 19:00:55 UTC, Nick Sabalausky wrote:
>> What I've been really wanting for a long time is the one-two combo of
>> Nemerle's variants and pattern matching:
>>
>> https://github.com/rsdn/nemerle/wiki/Grok-Variants-and-matching
>
> There is std.variant, though I haven't used it much myself and don't
> know how well it compares. Seems like that library would provide a good
> basis for providing pattern matching though.

This is one of those things where language support makes a big difference (like slices).

Algebraic is the *closest* thing in D that compared to Nemerle's variants...But honestly, saying std.variant compares to Nemerle's variants is like saying C can do high-order functions, OOP, and has a module system. Yea, *technically* you can, but it's so clunky by comparison that you're really not getting much of the real benefit.

One of the first examples on that page really highlights how it differs from D:

--------------------------------
// An equivalent std.variant.Algebraic would be clunky by comparison:
 variant RgbColor {
   | Red
   | Yellow
   | Green
   | Different {
       red : float;
       green : float;
       blue : float;
     }
 }
--------------------------------
string_of_color (color : RgbColor) : string
{
  match (color) {
    | RgbColor.Red => "red"
    | RgbColor.Yellow => "yellow"
    | RgbColor.Green => "green"
    | RgbColor.Different (r, g, b) => $"rgb($r, $g, $b)"
  }
}
--------------------------------

D can get close, but it's just not so clean, wouldn't scale as well, and that really does make a difference (just like how many of D's features are argued by others to be "not that big a deal", but we know that it is because we use it and know that extra bit of polish D gives makes a big difference).

And, yea, yea, Manu has a far better color color lib in D, but of course this is just an illustration of the language construct. It's one of those things (of which D really does have many - just not this one), that once you have it available and start using it, it's very liberating, and loosing it feels like having your hands tied.

It's not my #1 missed feature in D, but it would be nice.

On 10/23/2016 11:55 PM, Nick Sabalausky wrote:
>
> --------------------------------
> // An equivalent std.variant.Algebraic would be clunky by comparison:
>   variant RgbColor {
>     | Red
>     | Yellow
>     | Green
>     | Different {
>         red : float;
>         green : float;
>         blue : float;
>       }
>   }
> --------------------------------

Just to compare to equivalent D:

--------------------------------
struct RgbColor_ // Don't clutter the namepsace
{
    struct Red {}
    struct Yellow {}
    struct Green {}
    struct Different {
        float red;
        float green;
        float blue;
    }
}
alias RgbColor = Algenraic!(
    RgbColor_.Red,
    RgbColor_.Yellow,
    RgbColor_.Green,
    RgbColor_.Different,
}
--------------------------------

It's just...I mean, yea, it works, and you could probably DRY it up a little with a type contructing template ("alias RgbColor = DoMagic!RgbColor_"), but...meh...

And then the pattern matching end would be similarly "ehh...meh...":

--------------------------------
RgbColor color = ...;
auto x = color.visit(
    (RgbColor_.Red a) => "red",
    (RgbColor_.Yellow a) => "yellow",
    (RgbColor_.Green a) => "green",
    (RgbColor_.Red a) =>
        mixin(interpolateStr!`rgb(${a.red}, ${a.green}, ${a.blue})`),
);
--------------------------------

Again, technically works, but...ehh, it's like doing slices or high-order funcs in C.

On Monday, 24 October 2016 at 04:14:52 UTC, Nick Sabalausky wrote:
> It's just...I mean, yea, it works, and you could probably DRY it up a little with a type contructing template ("alias RgbColor = DoMagic!RgbColor_"), but...meh...

I think the following should be better. Instead of Proxy we would have a bespoke mixin which might fix some of the workarounds below. In the unittest, using with(Color) should help, but I couldn't get that to compile (visit thinks invalid lambdas are being passed).

import std.variant;

struct Color {
	struct Custom
	{
		float red;
		float green;
		float blue;
	}

	//mixin NewTypes!`Red, Yellow, Green`;
	struct Red {}
	struct Yellow {}
	struct Green {}

	private auto impl = Algebraic!(
		Custom,
		Red,
		Yellow,
		Green)();
	import std.typecons;
	mixin Proxy!impl;
}

unittest{
	Color color;
	// assignment works but not ctor
	color = Color.Custom(1, 2, 3);
	assert(color.type == typeid(Color.Custom));
	// FIXME: currently need impl
	auto x = color.impl.visit!(
		(Color.Red) => "red",
		(Color.Yellow) => "yellow",
		(Color.Green) => "green",
		(Color.Custom c) =>
			ctFormat!`rgb(%s, %s, %s)`(c.red, c.green, c.blue)
	);
	assert(x == "rgb(1, 2, 3)");
}

// TODO: implement ct parsing
auto ctFormat(string s, Args...)(Args args){
	import std.format;
	return format(s, args);
}

Someone may be, it will be interesting, in the C# 7 `switch` will be extended syntax for pattern matching:
https://github.com/dotnet/roslyn/blob/features/patterns/docs/features/patterns.md

Original post:
https://github.com/dotnet/roslyn/issues/206

On Friday, 28 October 2016 at 11:53:16 UTC, Nick Treleaven wrote:
> In the unittest, using with(Color) should help, but I couldn't get that to compile (visit thinks invalid lambdas are being passed).

https://issues.dlang.org/show_bug.cgi?id=16655