The re!() syntax extension accepts an string literal and optional flags, and returns an type T implementing CompiledRegularExpression:
re!("re_string_literal"[, options, ...]) -> T
The parse_re!() syntax extension just accepts an string literal and returns an type ReAst representing the regular expressions AST.
parse_re!("re_string_literal") -> ReAst
Both would be compiletime syntax checked, with nice error messages underlining spans of the string literal. re!() would compile the RE at compiletime, and exposing that to usercode as a specialized type and implementation of CompiledRegularExpression.
parse_re!() would basically just expand to an constructor expression for the ReAst type.
All this would also be duplicated as modules, types and functions in the re module for runtime compilation. Usage of CompiledRegularExpression for both compiletime and runtime compiled REs would ensure compatibilty and code reuse on the user side, and allows the option and flexibilty to plug in an custom runtime compiler and/or parser.
trait CompiledRegularExpression {
}
There would be no way to know what type re!() returns. The user would have to rely on inference, generics or trait objects to use it, wich however shouldn't really be a problem. The situation is similar to external Iterators and other OOP-like types in rust.