Case insensitive option with Regex.compile/2 - regex

Question

I'm attempting to build a caseless regex binary using Regex.compile/2 but can't seem to find an example on how the option should be set.
Regex.compile("^(foo):?", :caseless)
** (FunctionClauseError) no function clause matching in Regex.compile/3
The following arguments were given to Regex.compile/3:
# 1
"^(foo):?"
# 2
:caseless
# 3
"8.41 2017-07-05"
(elixir) lib/regex.ex:140: Regex.compile/3

Answer 1

In short
According to the link you provided, options need to be provisioned as a list as you can provide multiple options. The following should work:
Regex.compile("^(foo):?", [:caseless])
In more detail
The type specification is as follows:
compile(source, options \\ "")
compile(binary(), binary() | [term()]) :: {:ok, t()} | {:error, any()}
The second line is the type specification in dialyzer and basically states that the function compile accepts two arguments:
The first one is a binary, corresponding to your "^(foo):?"
The second one is either a binary, or either a list containing several terms.
The return value will be either {:ok, t()} in the case of success, where t() is a %Regex{} struct or either will be {:error, any()} in the case of an error.
Coming back to the discussion of the second parameter, in the case of a list, you will need to leverage the various options as mentioned here.
In the case of binary, you can provide the second argument as a one letter abbreviation. So whereas the following will fail:
Regex.compile("^(foo):?", "caseless")
The following on the other hand succeeds:
Regex.compile("^(foo):?", "i")
The mapping you can get from the table of the various module modifiers I linked to above.
The main difference between the approaches stems from the fact that Erlang Regex as powered by :re builds on top of the PCRE standard. According to that standard, the various module modifiers are handled by the single lower case letters, such as i, u etc.. So you could combine accordingly both options with binary as follows:
Regex.compile("^(foo):?", "iu")
which technically speaking should give you the equivalent of:
Regex.compile("^(foo):?", [:caseless, :unicode])
This allows you to communicate about Regex in Erlang and in Elixir through either the language specifications, or either the PCRE specifications.
Highly Advanced Details
As the OP rightly pointed out in the comments, there is some confusion as to why the Regex produced in two different ways(e.g. through options as list vs options as binary) looks differently.
To explain this discrepancy in more detail, consider the following scenarios:
r0 = Regex.compile!("(foo):?") ---> ~r/(foo):?/
r1 = Regex.compile!("(foo):?", "i") ---> ~r/(foo):?/i
--->~r/(foo):?/# ?????? WHERE IS THEi` ?????
When confronted with this, one might gain the impression that the Elixir Regex is broken. r0 and r2 are identical and different from r1.
However, functionality wise, r2 behaves like r1, not like r0, consider the following examples as shamelessly inspired by the comment of the OP:
Regex.replace(r0, "Foo: bar", "") ---> "Foo: bar"
Regex.replace(r1, "Foo: bar", "") ---> " bar"
Regex.replace(r2, "Foo: bar", "") ---> " bar"
So how is this possible?
If you recall from above, e.g. pertaining to the explanation of the type t(), a Regex in Elixir is nothing but a struct under the hood.
A Regex may be presented beautifully in the following way: ~r/(foo):?/, but in reality it is nothing but something like this:
%Regex{ opts: opts, re_pattern: re_pattern, re_version: re_version, source: source }
Now, from all those struct fields, the only thing that counts at the end of the day is what is under: re_pattern. That will contain the fully compiled Regex with all the options. So we find that accordingly:
r1.re_pattern == r2.re_pattern
But
r0.re_pattern != r2.re_pattern
As far as the opts field is concerned, that is a container solely reserved for the options in binary format. So you will find that:
- r0.opts == r2.opts == ""
Whereas:
- r1.opts == "i"
These same opts fields are utilized to beautifully display the options at the end of Regex accordingly, so you will see:
~r/(foo):?/ for both r0 as well as r2
But you will see:
~r/(foo):?/i for both r1
on account of the opts fields differing from each other.
It is for this reason that you could manually update the Regex if you would like it to look more consistent by doing this for instance:
%{r2 | opts: "i"} ---> ~r/(foo):?/i
Except for the field, re_pattern, none of the other fields have any functional influence to the actual Regex. Those other fields are merely there for the purpose of documentation only.
Next, on the basis of the source code, you can see that binary options get translated to the list version of options because that is how Erlang regex engine, :re expects them to be.
Even though not difficult in itself, the Elixir core team have opted not to provide translation for the reverse, e.g. from the actual list of module modifier atoms to the equivalent PCRE binary option, thus you end up with the opts field remaining empty and bereft of the corresponding options in PCRE binary format and thus, you end up with the defective rendering of the Regex as evidenced by the discrepancy above.
Above I have only delved into the mechanics that explain the discrepancy, however, whether such a discrepancy is warranted or not is another question in itself. I would be immensely grateful if someone with more insight than me could be so kind as to clarify if there is any way to defend such a discrepancy.
Conclusion
r0 = Regex.compile!("(foo):?") ---> ~r/(foo):?/
r1 = Regex.compile!("(foo):?", "i") ---> ~r/(foo):?/i
r2 = Regex.compile!("(foo):?", [:caseless]) ---> ~r/(foo):?/
r1 and r2 may look different, but they behave exactly the same.