/me is glad he grabbed it before github went down…

This looks quite nice, could clean up my type testing that I have scattered around. I am curious though, why does something like:

conform!(is_tuple() and &(tuple_size(&1) == 2), {1})

Take the value as the second argument instead of the first? It would be convenient to do things like:

value
|> conform!(is_tuple() and &(tuple_size(&1) == 2))
|> etc...

Also, on this example from your README.md:

iex> conform!(hello :: is_binary(), "world")
{:hello, "world"}

Have you thought about mandating this syntax instead:

iex> conform!(:hello :: is_binary(), "world")
{:hello, "world"}

That way we could tag it with anything, even a variable like:

iex> blah = :vwoop
iex> conform!(blah :: is_binary(), "world")
{:vwoop, "world"}

I will definitely use this when writing more elaborate behaviours/interfaces. It looks like a really clean way to structure conformity checks. Thank you for making this, @vic!

Hey @OvermindDL1, Thanks a lot for your feedback.

Well, while conform/2 expects the predicates (or any defined spec) inside of it to take the value as first argument (values are just piped into predicates), conform/2 itself expects its as second, I guess just because in Elixir functions use the first argument for the subject value, eg Regex.match(regex, string), so I guess I just went for Spec.conform(spec, value) naturally.

But if you do defspec and give it a name, then the resulting function will expect to work on the first value, applying the spec to it.

defp sum_tuple({a, b}, c) when a + b == c, do: true
defp sum_tuple({a, b}, c), do: false

defspec two_tuple(is_tuple() and &(tuple_size(&1) == 2))

value = {1, 2}

value
|> two_tuple()
|> sum_tuple(3)

So I guess having Spec.conform/2 take the spec as first argument (again just like many other things on Elixir) is better.

Regarding tags, you are irght, it could be useful to tag with a bound variable. Will change it and see how it feels.

Thanks for reading and giving input!