From @MARTIMM

Following code generates 'P6opaque​: must compose before allocating'.

package P {
  class Regex {
  has Int $.n;
  submethod BUILD ( Str :$n ) {
  die 'Not that one!!!' if $n ~~ m/^ '666' $/;
  $!n = $n.Int;
  }
  }
}

my P​::Regex $r .= new(​:n<777>);
say $r.n;

This error is generated because the matching test is somehow using the
class still to be build and
not referring to its proper Match/Regex class. Something in the
definition of infix​:<~~> perhaps.

Marcel

From @jnthn

On Wed Nov 25 02​:47​:48 2015, mt1957@​gmail.com wrote​:

Following code generates 'P6opaque​: must compose before allocating'.

package P {
class Regex {
has Int $.n;
submethod BUILD ( Str :$n ) {
die 'Not that one!!!' if $n ~~ m/^ '666' $/;
$!n = $n.Int;
}
}
}

my P​::Regex $r .= new(​:n<777>);
say $r.n;

This error is generated because the matching test is somehow using the
class still to be build and
not referring to its proper Match/Regex class. Something in the
definition of infix​:<~~> perhaps.

It's because a regex, like /^ 666/, actually has the type Regex, and the compiler resolves symbols using normal lexical scoping rules by default, so your Regex class hides the one defined by the Perl 6 setting. While the ability to replace core types is of course a useful feature for language extensibility, it's more likely to lead to confusion as in this ticket, so I've now tweaked the compiler to resolve Regex/Block/Sub/Parameter/Signature and similar directly in the current setting. This means that extensibility is still possible, but now requires the writing of a custom setting, which seems a fair burden to place on language extenders for the sake of everyone else. This policy applies also to exception types under the X​:: namespace. For everything else, the normal lexical scoping rules still apply.

Tests in S02-types/resolved-in-setting.t.

/jnthn

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

@jnthn - Status changed from 'open' to 'resolved'

From 1parrota@gmail.com

"This means that extensibility is still possible, but now requires the
writing of a custom setting, which seems a fair burden to place on
language extenders for the sake of everyone else."

That seems like a very reasonable policy; make life as convenient as
possible for the majority, but let the non-conformists do what they
want if it's worth their while.