Can you provide a small self-contained test case showing the problem? Thanks.

CC @mpvl

Sure thing.

package main

import (
    "log"
    "os"
    "regexp"
)

func main() {
    matched, err := regexp.MatchString(`[\p{ASCII_Hex_Digit}]`, "A")
    if err != nil {
        log.Fatal(err)
    }
    if !matched {
        os.Exit(1)
    }
}

The above program should exit cleanly but prints an error instead:

error parsing regexp: invalid character class range: `\p{ASCII_Hex_Digit}``

FWIW, the Unicode support in RE2 is also categories and scripts only. (google/re2@a6b34ea recently added the ability to build against ICU in order to have full Unicode properties support.)

In principle I don't see an issue with extending unicodetable to also check for references in Properties. There are a few drawbacks:

1. it will unconditionally pull in additional data (about ~10k as a very rough first estimate)
2. it doesn't stop there: there are many more property lists that are not in the core unicode package and would be weird not to support if the existing ones are supported (e.g. Alphabetic and Math are derived properties and are currently not defined in the unicode package).

If we want to go the same route as Google re2, this means pulling in ALL unicode binary property data. This adds up (all properties marked as binary in http://userguide.icu-project.org/strings/properties). My first estimate is that there are about 25 missing tables, roughly double what is in unicode.Properties now. A very wild guess is that supporting this would add about 30k worth of tables total. Not the worst, but still 30k.

So the possible solutions are:

1. Included Properties and extend it to include the missing tables.
2. Included Properties and compute the tables for derived properties other tables on the fly.
3. implement a mechanism for users to add more tables.
4. Don't support Properties at all.

It all depends what is considered to be an acceptable table increase. My first wild estimate is supporting all properties would add about 30k in tables to anyone using the regexp packages. Also people using unicode.Properties would be saddled up with 20k of additional (but possibly useful and welcome) data.

I think 1 is the best choice as it is the simplest and makes the sets of Properties defined in unicode a bit more comprehensive and consistent.

At the very least, the documentation should be updated to clearly reflect the valid values for \p, regardless of the implementation decision.

A plugin approach might be an option, similar to the way that image packages work, so that you only need to pull in the data for properties you care about. For instance, say, load emoji properties in unicode/properties/emoji, and only allow them to work if you load regexp/properties/emoji in your binary.

Current behavior is intended (scripts and categories only) but maybe we should reconsider. Will chat with @mpvl.