Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent resultant type of +@ slurpy when given a Seq #6306

Closed
p6rt opened this issue Jun 2, 2017 · 3 comments
Closed

Inconsistent resultant type of +@ slurpy when given a Seq #6306

p6rt opened this issue Jun 2, 2017 · 3 comments
Labels
LTA Less Than Awesome; typically an error message that could be better

Comments

@p6rt
Copy link

p6rt commented Jun 2, 2017

Migrated from rt.perl.org#131483 (status was 'rejected')

Searchable as RT131483$

@p6rt
Copy link
Author

p6rt commented Jun 2, 2017

From @zoffixznet

Some discussion​: https://irclog.perlgeek.de/perl6-dev/2017-06-02#i_14675550

The crux of it is the type of `+@​` slurpy changes, depending on the input, though on further examinations it seems only Seq is affected​:

m​: sub grab(+@​a) { dd @​a }; grab %(​:42a, :72b); grab (1, (2, 3)); grab [1, (2, 3)]; grab (1, (2, 3)).Seq
rakudo-moar 348891​: OUTPUT​: «[​:a(42), :b(72)]␤[1, (2, 3)]␤[1, (2, 3)]␤(1, (2, 3))␤»

In all of the examples above, the `@​a` ends up being an Array, except for the last case (with Seq input), where it's a List.

This leads to two issues​:
1) The inner list of the Seq did not get containerized, so we have inconsistencies in how the `+@​` slurpy flattens
2) The List is immutable, so doing something like `@​a[42] = 70` is currently never safe with a `+@​` slurpy, because
  for some inputs it might end up being a List.

Seems like the Seq case needs fixing so it ends up being an Array as well.

@p6rt
Copy link
Author

p6rt commented Dec 31, 2017

From @zoffixznet

On Fri, 02 Jun 2017 05​:26​:14 -0700, cpan@​zoffix.com wrote​:

Some discussion​: https://irclog.perlgeek.de/perl6-dev/2017-06-
02#i_14675550

The crux of it is the type of `+@​` slurpy changes, depending on the
input, though on further examinations it seems only Seq is affected​:

m​: sub grab(+@​a) { dd @​a }; grab %(​:42a, :72b); grab (1, (2, 3)); grab
[1, (2, 3)]; grab (1, (2, 3)).Seq
rakudo-moar 348891​: OUTPUT​: «[​:a(42), :b(72)]␤[1, (2, 3)]␤[1, (2,
3)]␤(1, (2, 3))␤»

In all of the examples above, the `@​a` ends up being an Array, except
for the last case (with Seq input), where it's a List.

This leads to two issues​:
1) The inner list of the Seq did not get containerized, so we have
inconsistencies in how the `+@​` slurpy flattens
2) The List is immutable, so doing something like `@​a[42] = 70` is
currently never safe with a `+@​` slurpy, because
for some inputs it might end up being a List.

Seems like the Seq case needs fixing so it ends up being an Array as
well.

Closing this in favour of rakudo/rakudo#1355 , which points out additional inconsistencies.

@p6rt
Copy link
Author

p6rt commented Dec 31, 2017

@zoffixznet - Status changed from 'new' to 'rejected'

@p6rt p6rt closed this as completed Dec 31, 2017
@p6rt p6rt added the LTA Less Than Awesome; typically an error message that could be better label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better
Projects
None yet
Development

No branches or pull requests

1 participant