On Sun, 10 Sep 2017 11:44:09 -0700, b...@abrij.org wrote:
> On Fri, 08 Sep 2017 21:13:59 -0700, b...@abrij.org wrote:
> > On Wed, 23 Aug 2017 06:20:49 -0700, b...@abrij.org wrote:
> > > On Mon, 24 Jul 2017 10:04:54 -0700, c...@zoffix.com wrote:
> > > > The coercion works fine here:
> > > >
> > > > 17:03 Zoffix m: class B {…}; class A { method B { B.new }};
> > > > class
> > > > B
> > > > {}; sub foo(B() $b) { say "hi" }; foo(A.new)
> > > > 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «hi?»
> > > >
> > > > But if I add `:D` smiley, it fails:
> > > >
> > > > 17:03 Zoffix m: class B {…}; class A { method B { B.new }};
> > > > class
> > > > B
> > > > {}; sub foo(B:D() $b) { say "hi" }; foo(A.new)
> > > > 17:03 camelia rakudo-moar 2fb8c7: OUTPUT: «Type check
> > > > failed
> > > > in binding to parameter '$b'; expected B but got A (A.new)? in
> > > > sub
> > > > foo at <tmp> line 1? in block <unit> at <tmp> line 1??»
> > > >
> > > > https://irclog.perlgeek.de/perl6/2017-07-24#i_14915397
> > >
> > > Seems to be more generic than custom classes:
> > >
> > > $ perl6 -e 'sub foo(Int() $b) { say $b }; foo("42")'
> > > 42
> > > $ perl6 -e 'sub foo(Int:D() $b) { say $b }; foo("42")'
> > > Type check failed in binding to parameter '$b'; expected Int but
> > > got
> > > Str ("42")
> > > in sub foo at -e line 1
> > > in block <unit> at -e line 1
> > >
> > > This raises the spec question, should e.g. IO:U($a) try to convert
> > > $a
> > > to an IO,
> > > and if that succeeds, succeed the bind with the type object of
> > > whatever doer (or
> > > subclass were IO a class) of IO which resulted? Or fail the bind?
> > > The latter is
> > > more consistent with the above desired behavior... but does
> > > "Class:D()" mean
> > > coerce-to-then-check-definedness, or go-all-out-to-make-a-defined-
> > > value?
> > >
> > > This doesn't make much sense yet either:
> > >
> > > $ perl6 -e 'Int:D(4).say'
> > > (Int:D)
> >
> >
> > This ticket and RT#126433 can be combined.
>
>
> I spent some more time digging into this. There are a couple layers
> to this issue.
>
> The first is a syntax conflict. Consider (example from specs):
>
> use Dog:auth(/:i jrandom/):ver(v1.2.1 | v1.3.4);
>
> ...in order to parse that the generic "extended identifier" syntax is
> allowed to
> take a statement list as the value of a colonpair-in-a-name. This is
> somewhat
> more liberal than what is normally allowed in a coercion type.
>
> Now in the S02, "extended identifiers" are said to only allow a
> "subscript-like adverbial form", which would exclude parens as the
> circumfix,
> so one solution to this would be to restrict the above syntax to
> useish statements only, or some broader but still limited syntactic
> category. There seems to be some logic for this already in token
> term:sym<name>,
> but not in token typename, which is where this case ends up.
>
> The second issue bears on the spec issue I raised above: if you do
> manage to
> chop through the syntax issues, then you have to decide whether the
> class
> coercion method that is called is named "B" or "B:D"... having
> separate
> methods for all smiley types could be advantageous, but would be
> tedious.
> Perhaps looking for "B:D" and if not found, calling "B" instead would
> be
> something to consider here.
>
> To pile on that, we get to the (NYI) behavior where the adverbial
> components
> of an extended identifier are supposed to be orderless, along with the
> prospect
> for compound smileys to be added later... cross that bridge when we
> get there I guess.
When fixing, please note also RT#130657
