@a.elems does not agree with +@a when a Positional type-object is bound to @a.

[gfldex]

sub foo(@a) { say [@a.elems, +@a] };
foo(List); # [1 0]

my @b := List; 
say [@b.elems, +@b]; # [1 0]

As discussed on IRC#raku-dev, this might be a result of a broader issue because we are asking a type object how many elements it contains or we allow type-objects to be bound to @-sigiled symbols eventhough they don't return anything useful on the promised interface that is Positional.

Environment

• Operating system: Linux dexhome 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) x86_64 GNU/Linux
• Compiler version (perl6 -v or raku -v): Welcome to Rakudo™ v2023.02-139-g47342e10d. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2023.02-3-g6adfc376c.

[lizmat]

One more reason for making my @a := List an execution error.

[lizmat]

FWIW, + means numification. Since @a is a List, you're numifying the List object, which numifies to 0. Now, visually, you'd think you're numifying an Array (which would call .elems), but you aren't.

To me, that's the nail in the coffin for allowing my @a := List.

[gfldex]

I agree on @a := List but wonder how we should handle the other case. If we ban explicit binding, why don't we stop explicit binding on @-sigiled parameters (that are not is-raw)?

[lizmat]

sub a(@a) { }
a(List);  # same code path as @a := List under the hood

[jnthn]

Potentially, 6.e could refine the type constraint of @ and % sigils to be Positional:D and Associative:D respectively, which would mean type objects are refused.