The various matching predicates can take either a Regex blob or a string pattern; if they are given a string pattern, they call re_compile/3 and cache the result; so, there is little reason to use re_compile/3 directly.

• anchored(Bool) If true, match only at the first position
• auto_capture(Bool) Enable use of numbered capturing parentheses. (default true)
• bsr(Mode) If anycrlf, \R only matches CR, LF or CRLF; if unicode, \R matches all Unicode line endings.
• bsr2(Mode) - synonym for bsr(Mode).
• caseless(Bool) If true, do caseless matching.
• compat(With) Error - PCRE1 had compat(javascript) for JavaScript compatibility, but PCRE2 has removed that.
• dollar_endonly(Bool) If true, $ not to match newline at end
• dotall(Bool) If true, . matches anything including NL
• dupnames(Bool) If true, allow duplicate names for subpatterns
• extended(Bool) If true, ignore white space and # comments
• firstline(Bool) If true, force matching to be before newline
• greedy(Bool) If true, operators such as + and * are greedy unless followed by ?; if false, the operators are not greedy and ? has the opposite meaning. It can also beset by a `(?U)` within the pattern - see the PCRE2 pattern internal option setting documentation for details and note that the PCRE2 option is UNGREEDY, which is the inverse of this packages greedy options. (default true)
• compat(With) Raises an errr - PCRE1 had compat(javascript) for JavaScript compatibility, but PCRE2 has removed that option . Consider using the alt_bsux and extra_alt_bsux options.
• multiline(Bool) If true, ^ and $ match newlines within data
• newline(Mode) If any, recognize any Unicode newline sequence; if anycrlf (default), recognize CR, LF, and CRLF as newline sequences; if cr, recognize CR; if lf, recognize LF; crlf recognize CRLF as newline; if nul, recognize the NULL character (0x00) as newline.
• newline2(Mode) - synonym for newline(Mode).
• ucp(Bool) If true, use Unicode properties for \d, \w, etc.
• utf_check(Bool) - see PCRE2 API documentation You should not need this because SWI-Prolog ensures that the UTF8 strings are valid,
• endanchored(boolean) - see PCRE2 API documentation
• allow_empty_class(boolean) - see PCRE2 API documentation
• alt_bsux(boolean) - see PCRE2 API documentation
• auto_callout(boolean) - see PCRE2 API documentation
• match_unset_backref(boolean) - see PCRE2 API documentation
• never_ucp(boolean) - see PCRE2 API documentation
• never_utf(boolean) - see PCRE2 API documentation
• auto_possess(boolean) - see PCRE2 API documentation (default true)
• dotstar_anchor(boolean) - see PCRE2 API documentation (default true)
• start_optimize(boolean) - see PCRE2 API documentation (default true)
• utf(boolean) - see PCRE2 API documentation
• never_backslash_c(boolean) - see PCRE2 API documentation
• alt_circumflex(boolean) - see PCRE2 API documentation
• alt_verbnames(boolean) - see PCRE2 API documentation
• use_offset_limit(boolean) - see PCRE2 API documentation
• extended_more(boolean) - see PCRE2 API documentation
• literal(boolean) - see PCRE2 API documentation
• match_invalid_utf(boolean) - see PCRE2 API documentation
• jit_complete(boolean) - see PCRE2 API documentation
• jit_partial_soft(boolean) - see PCRE2 API documentation
• jit_partial_hard(boolean) - see PCRE2 API documentation
• jit_invalid_utf(boolean) - see PCRE2 API documentation
• jit(boolean) - see PCRE2 API documentation (default true)
• copy_matched_subject(boolean) - see PCRE2 API documentation

In addition to the options above that directly map to PCRE flags the following options are processed:

• optimise(Bool) or optimize(Bool) Turns on the JIT compiler for additional optimization that greatly that speeds up the matching performance of many patterns. (Note that he meaning has changed slightly from the PCRE1 implementation
• PCRE2 always optimises where possible; this is an additional optimisation.)
• capture_type(+Type) How to return the matched part of the input and possibly captured groups in there. Possible values are:

  string

  Return the captured string as a string (default).

  atom

  Return the captured string as an atom.

  range

  Return the captured string as a pair Start-Length. Note that we use Start-Length rather than the more conventional Start-End to allow for immediate use with sub_atom/5 and sub_string/5.

  term

  Parse the captured string as a Prolog term. This is notably practical if you capture a number.

The capture_type specifies the default for this pattern. The interface supports a different type for each named group using the syntax `(?<name_T>...)`, where T is one of S (string), A (atom), I (integer), F (float), N (number), T (term) and R (range). In the current implementation I, F and N are synonyms for T. Future versions may act different if the parsed value is not of the requested numeric type.

Note that re_compile/3 does not support the Pattern/Flags form that is supported by re_match/3, re_replace/4, etc.; the Pattern must be text and all compile options specified in Options.