Makes sense. I went with TypeName{'arg'} and TypeName<arg> instead of
TypeName['arg'] which is actually better in some ways. I wanted it to look
like Type::Tiny a bit but I guess that's what inbuilt types are for :)

On Wed, Oct 7, 2015 at 2:53 AM, jn...@jnthn.net via RT <
perl6-bugs-follo...@perl.org> wrote:

> On Thu Aug 06 06:18:57 2015, lloyd.fo...@gmail.com wrote:
> > Context: I am trying to make a fun syntax where Class[@args] is an alias
> > for Class.new(@args)
> >
> > -----
> > class C {};
> > sub postcircumfix:<[ ]>(C:U $c, Str $arg){ say 'win' };
> > my $c = C;
> > $c['test']; #-> win
> > C['test'];  #!> C cannot be parameterized
> >
> > ------
>
> The syntax TypeName[...] is syntactically a type parameterization, by
> design. If you really want to force interpretation as an array indexing,
> it'd have to be written as:
>
> C.['test']; #-> win
>
> > I also tried:
> > ------
> > role R { method parameterize(|) { say $*d; } };
> > class C {};
> > BEGIN { C.HOW does R };
> > my $*d = 'win';
> > C[my $a = 'test']; #-> win
> > C['test']                #!> Dynamic variable $*d not found
> >
> > ------
> > But I can't use dynamic variables because if it's called with a compile
> > time variable it runs .parameterize at compile time only.
> >
> Yes, and we're allowed to form parametric types at compile time whenever
> we know we have the parameters available (and if we can't do that, we have
> a lot of problems; for one it's the very mechanism that allows you to
> `does` a parametric role on a class declaration!) A parameterize method
> that isn't prepared to be called at compile time is buggy.
>
> > I tentatively suggest that at least one of these is a bug as they
> together
> > prevent you using [] on a type to callback to something using $*dynamic
> > variables consistently.
>
> Both behaviors are as intended. In general, anything of the form
> `<typename> <postcircumfix>` should be considered a special form. It's a
> pity we have to overload bracketing chars, but sadly ASCII is a bit
> limiting!
>
> Thanks,
>
> Jonathan
>
>

Reply via email to