Histórico de mensagens em sugestões

se eu tiver que usar um OR já se torna uma salada desnecessária

<@!440035527127990273> , no seu caso, você teria que usar muitas saladas de opções?

eu preferiria mil vezes continuar com suporte a regex sem parênteses do que ter uma salada de opções

aceitando qualquer regex sem parênteses não terá esse problema de iteração de duplo nível entre + e , e , etc

o problema aqui não é a existência de parênteses? não tem razão nenhuma pra aceitar parênteses se eu não vou reutilizar os matchs individuais.

<@!793123559874494465> uma alternativa seria usar algo como o % do MySQL. Assim, poderíamos ter:

Tipo assim:

<@!370847985199742977> eu acho que é possível dar uma simplificada no input, de forma que, no final das contas, não importa se o backend trata o match com ifs ou glob ou até uma "regex confiável"

é o regexp de pobre... o já resolve o começa com, termina com e contém haha

Pensando sobre glob.

Na verdade, a ideia é que o integrador não precisa usar tantos comecaCom ou terminaCom...

não poderia então simplificar o regex por um glob?

e provavelmente daria até menos trab para conciliar tantas regras de "comecaCom", "terminaCom" "E" "OU", etc

acho que seria mais flexível com a expressão

no momento eu não pretendo nem usar isso

<@!370847985199742977> você tem algum caso de uso que ficaria comprometido com essa restrição?

Sim. Então algo a documentar, caso seja único, é que pode-se usar a possibilidade de ter chaves distintas para ter regras distintas, caso necessário.

Sim, varia somente o tamanho. Os caracteres são conhecidos.

sem contar que pode usar um engine de regex simplificado, retirando backtracking por ex

A separação por chaves continua existindo, cada chave pode possuir as suas regras específicas.