On Mon, Feb 19, 2018 at 11:43 AM, Isiah Meadows <isiahmead...@gmail.com>

> Yes, and I specifically want the conservative variant - I'd want a
> "maybe" for "foo" in that example.
> (For context, my test framework determines *while running a test*
> whether that test has children, and checks whether to allocate them
> when defining them. For me, I only need "yes/maybe" and "no", but
> splitting "yes" and "maybe" could be beneficial to others.)

Ok, so you're trying to decide whether to prune a graph search based
on a regexp that classifies paths through the graph.

We can't base a distinction between yes and maybe on whether a
zero-width $ assertion is triggered if there are paths to completion
that do not pass through that assertion.

const re = /^foo($|d).?/
// This variant uses the $ assertionconsole.log(
  re.exec("foo")[0] === 'foo')// yes would be inappropriate, but
yes|maybe would be because
// This variant uses the dconsole.log(
  re.exec("food")[0] === 'food')// and yes|maybe would be appropriate here since
  re.exec("foods")[0] === 'foods')

So IIUC, the yes/maybe distinction could be based on a bit that is set on
success of a $ assertion and erased on exit from any of ( ...|... , ...? ,
...* , ...{0,...} , (?!...) ).
That only works when we know that the start of the match is stable though

const re = /foo$/

It would hold for the common case /^...$/ but in that case you already know
the answer, and can test it at runtime by testing myRegExp.source matches a
meta-pattern like /^\^([^\\]|\\[\s\s])*\$$/.
es-discuss mailing list

Reply via email to