Elixir allows you to define your own data-structures as structs, on top of Erlang maps. However, such user-defined types have always felt a little ‘off’ from the built-in types, because they do not get the same level of support. Most notably, it is (used to be) virtually impossible to define a guard clause that properly works with your struct, because of two problems:

1. Destructuring maps inside a guard clause was not possible. OTP 21 changes this, with the introduction of the guard-safe :erlang.map_get/2 and :erlang.is_map_key/2 functions.
2. It is not possible to perform conditionals inside a guard clause; the thing that comes the closest is :erlang.andalso/2/:erlang.oreither/2 (in Elixir exposed as and and or respectively), which however require that the left-hand-side always evaluates to a boolean.

However, today I realized that there is a solution for (2): We could create a compile-time macro that creates multiple function-heads with the different versions of the macro below one-another!

An example

I have in the past created the library Ratio that allows rational numbers. It would be great if you could just use the built-in arithmetic and comparison operators on these structures. However, until now it was impossible to do so: We want to be able to

• compare %Ratio{} to %Ratio{}
• %Ratio{} to integer,
• integer to %Ratio{},
• and still allow integer ↔ integer comparisons.

If def and defp were to be altered to, whenever a comparison operation would be used in a guard, expand the function into multiple clauses, each with the next guard, then these kinds of operations would now be possible!

Important advantages

• It will finally be possible to treat our custom types as built-in ones, by having proper guard-safe functions work on them.
• Related to this, it will be possible to override or extend the built-in operators so they will work properly for custom datastructures as well, which will (a) remove one hurdle for newcomers when coming to the language and (b) improve the readability of our code.

Disadvantages

Two disadvantages come to mind:

1. The difference between the code you write and what it compiles to increases slightly. This might have an impact on the debug-ability of some code. However, because you see, for instance, the expanded guards right next to an ArgumentError-stacktrace and because people should not nest multiple layers of abstraction in the same guard clause anyway, I think this might not be that much of a disadvantage.
2. Increased code size. Either the function body is copied multiple times, ones per guard clause, or an extra level of call-indirection is done. Either might be optimized away by the BEAM however (I have not yet done any checks to see this). Another possibility would be to compile such a multi-guard down to an Erlang ,-separated (comma-separated) guard clause set, which is the built-in way Erlang allows multiple clauses to dispatch to the same function body.

All right, that was all I had to say for now.

Opinions? Ideas? Suggestions?