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

Inconsistency in .trans()'s handling of duplicate replacement chars #6066

Open
p6rt opened this issue Feb 11, 2017 · 1 comment
Open

Inconsistency in .trans()'s handling of duplicate replacement chars #6066

p6rt opened this issue Feb 11, 2017 · 1 comment

Comments

@p6rt
Copy link

@p6rt p6rt commented Feb 11, 2017

Migrated from rt.perl.org#130762 (status was 'new')

Searchable as RT130762$

@p6rt

This comment has been minimized.

Copy link
Author

@p6rt p6rt commented Feb 11, 2017

From @zoffixznet

https://irclog.perlgeek.de/perl6/2017-02-11#i_14084570

When duplicate replacement chars are given, the first replacement is used when no named args are present but last (or later?) replacement is used when there are any named args

16​:36 IOninja m​: say "abc".trans("abc" => "XYZ", :meows)
16​:36 camelia rakudo-moar 266f34​: OUTPUT«XYZ␤»
16​:36 IOninja m​: say "abc".trans("aba" => "XYZ", :meows)
16​:36 camelia rakudo-moar 266f34​: OUTPUT«ZYc␤»
16​:36 IOninja m​: say "abc".trans("aba" => "XYZ")
16​:36 camelia rakudo-moar 266f34​: OUTPUT«XYc␤»
16​:37 ufobat ha :)
16​:38 IOninja ufobat​: looks like indeed a bug (inconsistency) on how duplicates are processed between .trans with named args and without. It follows one codepath without any named args and if there are any, changes the replacement to list form and that apparently uses different path for dups
16​:38 ufobat should i, will you create a bug report?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.