[iopq]

I did FizzBuzz in Rust without using ifs:

https://bitbucket.org/iopq/fizzbuzz-in-rust/src/bf4968973d73...

[vvanders]

I'm more of a fan of the zip/cycle approach:

https://play.rust-lang.org/?gist=3fb51314d7df9249c9f774dde96...

[iopq]

My approach works with arbitrary conditions, that's why it takes closures as arguments. So it's a little bit of a different requirement, I wanted something as general as possible.

[bradmwalker]

Python https://gist.github.com/bradmwalker/b300f36e9427f729b458

[iopq]

I like this approach. The only thing I would criticize is that it uses '' as a substitute for None.

So something like

    fizzes, buzzes, empties = str_cycle('Fizz', 3), str_cycle('Buzz', 5), str_cycle('', 7)

wouldn't work since it would print 7 instead of the empty string

[hughes]

This looks dreadfully complex.

[iopq]

It's all type signatures. The actual function is seven lines.

[iainmerrick]

This looks complexly dreadful.

[jkcxn]

Here is something similar I did in JS

https://gist.github.com/JakeCoxon/d78fa1debc13e46ae54a

[zcoyle]

I came up with nearly the same solution in swift:

https://github.com/zachcoyle/fizzbuzz-without-booleans/blob/...

But I like your solution better

[urschrei]

You've qualified your approach in various ways downthread, but you can avoid ifs far more easily with two simple enums and two match statements. https://github.com/urschrei/rust_fizzbuzz/blob/by_reference/...

[iopq]

I also wanted to avoid match expressions as well

[ronnier]

I'd hate to maintain that.

[kibwen]

On the contrary, I'm fascinated by the prospect of a job where I'd be paid to abuse type systems to produce useless programs. :)

[iopq]

On the contrary, once you understand how it works, it's trivial to change the program

Let's say you wanted to change the program to yield "Fizzbuzz" instead of "FizzBuzz" in the 15 case, but the rest being the same.

I would first build my string from "fizz" and "buzz" and then I'd have to do .map(capitalize) as the second to last step. If I wanted to have the correct case in the originating strings I could just run them into to_lowercase first before anything happens and capitalize correctly afterwards.

(Actually, the capitalize function itself is probably more complicated than this change)

Similarly, other changes are intuitively easy to stick into the correct place in the program once you know what this program does.