# New Ticket Created by Christian Bartolomaeus # Please include the string: [perl #124079] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org/Ticket/Display.html?id=124079 >
bartolin m: my Str @a = (1, 2); camelia rakudo-moar 1fdb76: OUTPUT«Unhandled exception: Type check failed in assignment to '@a'; expected 'Str' but got 'Int' at <unknown>:1 (/home/camelia/rakudo-inst-1/languages/perl6/runtime/CORE.setting.moarvm:throw:4294967295) from src/gen/m-CORE.setting:15614 (/home/camelia/…» bartolin m: my Str @a = (1, 2); 1 camelia rakudo-moar 1fdb76: ( no output ) bartolin why didn't the second command not blow up like the first? s/not// TimToady m: { my Str @a = (1, 2) }; 1 camelia rakudo-moar 1fdb76: OUTPUT«Type check failed in assignment to '@a'; expected 'Str' but got 'Int' in method REIFY at src/gen/m-CORE.setting:10856 in method reify at src/gen/m-CORE.setting:9466 in method gimme at src/gen/m-CORE.setting:9949 in method sink at src/gen/m-…» TimToady m: { my Str @a = (1, 2); 1 }; 1 camelia rakudo-moar 1fdb76: ( no output ) TimToady looks like a bug relating to explicit sinking somehow psch m: my Str @a = 1, 2; 1; @a[0] camelia rakudo-moar 1fdb76: OUTPUT«WARNINGS:Useless use of constant integer 1 in sink context (line 1)Type check failed in assignment to '@a'; expected 'Str' but got 'Int' in method REIFY at src/gen/m-CORE.setting:10856 in method reify at src/gen/m-CORE.setting:9466 in met…» TimToady m: sink my Str @a = (1, 2); camelia rakudo-moar 1fdb76: OUTPUT«Type check failed in assignment to '@a'; expected 'Str' but got 'Int' in method REIFY at src/gen/m-CORE.setting:10856 in method reify at src/gen/m-CORE.setting:9466 in block at src/gen/m-CORE.setting:9449 in method reify at src/gen/m-CORE.…» psch that points to laziness, doesn't it? TimToady m: lazy my Str @a = (1, 2); camelia rakudo-moar 1fdb76: OUTPUT«Unhandled exception: Type check failed in assignment to '@a'; expected 'Str' but got 'Int' at <unknown>:1 (/home/camelia/rakudo-inst-1/languages/perl6/runtime/CORE.setting.moarvm:throw:4294967295) from src/gen/m-CORE.setting:15614 (/home/camelia/…» psch i.e. the array assignment is lazy, and the 1 in sink context makes it not care? TimToady pseudo assignment should be eager on my (though not on constant) * psch mentally shoves that on the "GLR-problems" heap TimToady m: our Str @a = (1, 2); camelia rakudo-moar 1fdb76: OUTPUT«5===SORRY!5=== Error while compiling /tmp/5lWhIQ3auGCannot put a type constraint on an 'our'-scoped variableat /tmp/5lWhIQ3auG:1------> 3our Str @a7⏏5 = (1, 2); expecting any of: constraint» TimToady well phoo * TimToady thinks our should at least allow identical type assignments /assignments/constraints/ AFAIU assigning elements of the wrong type to a typed array should lead to an exception regardless of what code follows.