# New Ticket Created by "Carl Mäsak" # Please include the string: [perl #114886] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=114886 >
<TimToady> in http://rosettacode.org/wiki/FizzBuzz#Perl_6 the second solution should not require 'is default' according to S12:1210 <TimToady> masak: ^ rakudobug <masak> TimToady: are you able to demonstrate it golfed on p6eval? that helps. <TimToady> r: multi sub fizzbuzz(Int $ where * %% 15) { 'FizzBuzz' }; multi sub fizzbuzz(Int $ where * %% 5) { 'Buzz' }; multi sub fizzbuzz(Int $ where * %% 3) { 'Fizz' }; multi sub fizzbuzz(Int $number) { $number }; (1 .. 100)».&fizzbuzz.join("\n").say; <p6eval> rakudo 100727: OUTPUT«Ambiguous call to 'fizzbuzz'; [...] <TimToady> :) <TimToady> I golfed it by removing some newlines :P <jnthn> That's because I disagree with the spec so deliberately didn't follow it. :) <jnthn> I think you *shouold* need "is default" rather than relying on ordering. <TimToady> I don't * moritz also finds that spec highly dubious <jnthn> Because when you've multis that are imported, ordering is dodgy. <TimToady> and the paragraph in question gives the rationale <jnthn> TimToady: It seems cute today. :) <masak> I think I agree with jnthn, too. but a rakudobug is a rakudobug. <jnthn> I have a bad feeling it'll be less cute in the future. * masak submits rakudobug <TimToady> I think it's a necessity to avoid forcing people into using 'is default' where that would be even boguser <jnthn> When is it boguser? <TimToady> most of the time * jnthn doesn't see how it's bogus in this case, fwiw. <moritz> and, when isn't it bogus? <jnthn> Source code ordering just feels to me like a poor tie-breaker of last resort, that's all. <TimToady> so we substitute a poorer one <jnthn> I don't find being explicit about what you want poorer. I guess I don't see the real issue yet. <[Coke]> ordering gives you a rank, is default gives you "the best" ? <[Coke]> I can't imagine doing something that crazy with multis and expecting it to work either way, though. <jnthn> It only comes up when you have constraints that are not mutually exclusive. <[Coke]> Seems like making it clear from the signature would be best. <[Coke]> jnthn: at which point a sane person would have a multi with a switch in it. <jnthn> [Coke]: That is one way to look at it :) <jnthn> I can see the attraction to using multis here, though. <TimToady> the upside is much bigger than the downside, in my estimation <jnthn> But yeah, the given/when feels more robust. <moritz> one can still do (Int $ where { $_ %% 5 && $_ % 3}) <TimToady> one can be as unclear as one likes, but lack of clarity is not what we're optimizing for here
