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

Ranges can be modified through .bounds in Rakudo; supposed to be immutable #4467

Closed
p6rt opened this issue Aug 11, 2015 · 6 comments
Closed

Comments

@p6rt
Copy link

p6rt commented Aug 11, 2015

Migrated from rt.perl.org#125791 (status was 'resolved')

Searchable as RT125791$

@p6rt
Copy link
Author

p6rt commented Aug 11, 2015

From @smls

Ranges are supposed to be immutable value types, and they do work that way w.r.t object identity comparison​:

  ➜ my $r = 5..10;
  ➜ $r === 5..10;
  True

However, the .bounds method returns item containers which, when assigned to, affect the original Range object​:

  ➜ $r.bounds[1] = 8;
  ➜ say $r
  5..8

The .bounds method should probably be made to decontainerize its return values, to fix this.

@p6rt
Copy link
Author

p6rt commented Aug 11, 2015

From @lizmat

Fixed with 7814349, tests added with d649801, can be closed

On 11 Aug 2015, at 18​:26, Sam S. (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Sam S.
# Please include the string​: [perl #​125791]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=125791 >

Ranges are supposed to be immutable value types, and they do work that way w.r.t object identity comparison​:

➜ my $r = 5..10;
➜ $r === 5..10;
True

However, the .bounds method returns item containers which, when assigned to, affect the original Range object​:

➜ $r.bounds[1] = 8;
➜ say $r
5..8

The .bounds method should probably be made to decontainerize its return values, to fix this.

@p6rt
Copy link
Author

p6rt commented Aug 11, 2015

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Aug 14, 2015

From @usev6

I adjusted the test with commit 17d9681 so that it passes on JVM as well. I'm closing this ticket as 'resolved'.

[Please note​: The change to the test was needed because X​::Assignment​::RO didn't get the typename right on JVM. That has nothing to do with .bounds as shown here​:

$ perl6-m -e '2 = 3'
Cannot modify an immutable Int
  in block <unit> at -e​:1

$ perl6-j -e '2 = 3'
Cannot modify an immutable value
  in block <unit> at -e​:1
]

1 similar comment
@p6rt
Copy link
Author

p6rt commented Aug 14, 2015

From @usev6

I adjusted the test with commit 17d9681 so that it passes on JVM as well. I'm closing this ticket as 'resolved'.

[Please note​: The change to the test was needed because X​::Assignment​::RO didn't get the typename right on JVM. That has nothing to do with .bounds as shown here​:

$ perl6-m -e '2 = 3'
Cannot modify an immutable Int
  in block <unit> at -e​:1

$ perl6-j -e '2 = 3'
Cannot modify an immutable value
  in block <unit> at -e​:1
]

@p6rt p6rt closed this as completed Aug 14, 2015
@p6rt
Copy link
Author

p6rt commented Aug 14, 2015

@usev6 - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant