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

Move and refactor the multi-dim candidates of postcircumfix { } #1139

Closed
wants to merge 4 commits into from

Conversation

smls
Copy link
Contributor

@smls smls commented Aug 27, 2017

...to implement them more similarly to the multi-dim candidates of postcircumfix [ ].

This fixes:

Testing

Move them to multidim_slice.pm, where the postcircumfix[;] ones have
already been moved last year with commit bb662ff.
…rcumfix[;]

postcircumfix[;] has seen significant refactors/optimizations, but
postcircumfix{;} was seemingly left behind. This commit brings it in
line (though only the default candidate for now, i.e. without
adverbs or binding.)

It now passes multiple arguments to .AT-KEY in case of mutidimensional
scalar subscripts, just like .[] already did with .AT-POS.

The default implementations of the *-KEY methods provided by class
Any have been updated to handle this.

(This also fixes RT #130947)
The other associative classes (Map, Hash, Pair, etc.) inherit the
default implementation from Any, but role TypedHash overrides
it so it has to call the multi-dim Any candidate manually.
Multi-dimensional postcircumfix [ ] returned a slice (List) instead
of a scalar element, unless the key at every dimensions was an Int.

(Same with postcircumfix { } and Str, since commit 2faed16.)

That was incorrect. Now, a slice is only returned if any dimension
has an Iterable or Whatever/HyperWhatever key.

Example test-case that now passes:

    my @A = [1, [[2, 3, 4], 5, [6, 7]]];
    is-deeply @A[1; 0.0; "2"],  4, 'indices are coerced to integers';
@JJ
Copy link
Collaborator

JJ commented May 3, 2020

Can you please have a look at this? It's got conflicts with the new base.

@JJ JJ added consistency easy to resolve This issue is likely easy for beginners to resolve Needs Help PR needs to picked up by somebody labels Aug 5, 2020
@lizmat
Copy link
Contributor

lizmat commented Jan 13, 2021

The array issue appears to have been resolved with 2017.12. The hash issue still exists. But since I have recently re-imagined array slices, and am looking at re-imagining hash slices, I think this PR can be closed. The issue should remain open though.

@lizmat
Copy link
Contributor

lizmat commented Jan 5, 2022

Closing this PR now

@lizmat lizmat closed this Jan 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consistency easy to resolve This issue is likely easy for beginners to resolve has conflicts Needs Help PR needs to picked up by somebody
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants