From @briandfoy

The |, ^, and & character class (and Unicode property) set operators
aren't parseable​:

  > / <[abc] | [def]> /
  ===SORRY!=== Error while compiling​:
  Unable to parse expression in metachar​:sym<assert>; couldn't find final '>'
  ------> / <[abc]⏏ | [def]> /
  > / <[abc] ^ [def]> /
  ===SORRY!=== Error while compiling​:
  Unable to parse expression in metachar​:sym<assert>; couldn't find final '>'
  ------> / <[abc]⏏ ^ [def]> /
  > / <[abc] & [def]> /
  ===SORRY!=== Error while compiling​:
  Unable to parse expression in metachar​:sym<assert>; couldn't find final '>'
  ------> / <[abc]⏏ & [def]> /
  > / <[abc] + [def]> /
  / <[abc] + [def]> /
  > / <[abc] - [def]> /
  / <[abc] - [def]> /

These are documented in https://docs.perl6.org/language/regexes but are
not marked as "not implemented" or something similar.

From @jnthn

On Tue, 27 Dec 2016 14​:32​:45 -0800, comdog wrote​:

These are documented in https://docs.perl6.org/language/regexes but
are
not marked as "not implemented" or something similar.

I doubt they'll be implemented particularly soon; I suggest they are removed from the docs.

The RT System itself - Status changed from 'new' to 'open'

From @coke

On Fri, 30 Dec 2016 13​:36​:03 -0800, jnthn@​jnthn.net wrote​:

On Tue, 27 Dec 2016 14​:32​:45 -0800, comdog wrote​:

These are documented in https://docs.perl6.org/language/regexes but
are
not marked as "not implemented" or something similar.

I doubt they'll be implemented particularly soon; I suggest they are
removed from the docs.

Opened a docs ticket to cover it.

Raku/doc#1093

Rejecting this ticket.

--
Will "Coke" Coleda

@coke - Status changed from 'open' to 'rejected'

From @briandfoy

I notice that in many other places in the docs there are "NYI" annotations. Perhaps that would be appropriate here. I figure that this ticket would need to come back to satisfy the UTS #​18 (http://www.unicode.org/reports/tr18/tr18-19.html) support. Perhaps mark it as stalled?

@briandfoy - Status changed from 'rejected' to 'stalled'

From @briandfoy

If these are intended to be future features (and for Unicode
compliance I think they are), maybe mark it as stalled instead. I tend
to think of rejected tickets as not valid or wrong, which this one
isn't. It's still something that needs to happen in the future.

The RT System itself - Status changed from 'stalled' to 'open'

From @AlexDaniel

I've raised this question too ( https://irclog.perlgeek.de/perl6/2016-12-31#i_13827103 ), but according to Coke​:
“no. there's no intent to implement it.”

Perhaps someone can doublecheck, but looks like there's no reason to keep this open.

On 2017-01-02 13​:27​:48, comdog wrote​:

If these are intended to be future features (and for Unicode
compliance I think they are), maybe mark it as stalled instead. I tend
to think of rejected tickets as not valid or wrong, which this one
isn't. It's still something that needs to happen in the future.

From @briandfoy

If it's going to be rejected, a note about why Perl 6 will not have
full, basic Unicode support (Level 1) would be nice.

From @AlexDaniel

On 2017-01-02 13​:51​:27, comdog wrote​:

If it's going to be rejected, a note about why Perl 6 will not have
full, basic Unicode support (Level 1) would be nice.

I'm not sure I understand the issue here…
It does support properties, and you can already use + and - (and | was supposed to be an equivalent to + I think, so just use + instead).

So if you want something like <​:Ll + :N>, then it already works. Now, the only question is how would you do intersections, in which case you can use something like this​:

say ‘pyõrl6’ ~~ m/[<​:Ll> & <​:Block(‘Basic Latin’)>]+/ # OUTPUT«｢py｣»

I don't mind & being added, as much as I don't mind it being rejected. But I don't really see the point about basic unicode support (or the lack of thereof). Perhaps you can clarify?

From @jnthn

On Mon, 02 Jan 2017 14​:15​:45 -0800, alex.jakimenko@​gmail.com wrote​:

On 2017-01-02 13​:51​:27, comdog wrote​:

If it's going to be rejected, a note about why Perl 6 will not have
full, basic Unicode support (Level 1) would be nice.

I'm not sure I understand the issue here…
It does support properties, and you can already use + and - (and | was
supposed
to be an equivalent to + I think, so just use + instead).

So if you want something like <​:Ll + :N>, then it already works. Now,
the only
question is how would you do intersections, in which case you can use
something
like this​:

say ‘pyõrl6’ ~~ m/[<​:Ll> & <​:Block(‘Basic Latin’)>]+/ # OUTPUT«｢py｣»

I don't mind & being added, as much as I don't mind it being rejected.
But I
don't really see the point about basic unicode support (or the lack of
thereof). Perhaps you can clarify?

To be clear, my "doubt they'll be implemented soon" wasn't an indication they shouldn't be, just that it's better that the docs cover things that actually exist. If somebody popped up with a patch to implement them tomorrow, that'd be just great. But, as mentioned by Alex, there is already a way to do it, and at the moment most folks are more focused on making the many features we already have robust and fast rather than adding more features. Thus my uncertainty whether it'll top anybody's todo list especially soon. Of course, now I've written this somebody will probably be like "hah, challenge accepted!" :-)

I'll re-title this ticket to be an NYI for the features; it's right that we have a ticket to track that it wants doing at some point.

/jnthn

From @AlexDaniel

Also​:

“I notice that in many other places in the docs there are "NYI" annotations.”

Please file doc tickets for these. Most of the time we don't want to doc NYI stuff.

On 2016-12-30 23​:24​:46, comdog wrote​:

I notice that in many other places in the docs there are "NYI"
annotations. Perhaps that would be appropriate here. I figure that
this ticket would need to come back to satisfy the UTS #​18
(http://www.unicode.org/reports/tr18/tr18-19.html) support. Perhaps
mark it as stalled?