51–60 of 139 posts
Earlier quoted context omitted.
But shouldn't they (String and slice) have some common super type to make this all easy to use ?
Yes. It's a design bug that String and slice don't share a common trait and that `.as_slice()` is common simply to use slice methods. I expect that to be fixed before 1.0.
In the contrived Python example, FizzBuzzItem is only called if the result is a number (not in any of the modulo 0 cases) - is that intended? I can see that it works, but it's breaking the analogy for me with the Rust code.
Whoa, that was indeed a mistake. Sorry about that. Fixed.
Earlier quoted context omitted.
But shouldn't they (String and slice) have some common super type to make this all easy to use ?
Also, the location of storage is slightly more visible (in general) in Rust than in other languages. I have personally found this to be pretty clarifying, because as much a we may like to abstract over it, the location of storage often worms its way into the programming model even in HLLs.
Earlier quoted context omitted.
Whoa, that was indeed a mistake. Sorry about that. Fixed.
Thanks, also is the "try it" link on rust playpen linking to the wrong code?
Earlier quoted context omitted.
yeah, no one writes python like this.
I've seen it quite frequently and kindof like it because it doesn't introduce any state that could leak out or get mutated from somewhere else. Although the ternary operator doesn't make as much sense in python as in other languages since there is no const keyword, otherwise that's what the ternary operator is usually used for.
Earlier quoted context omitted.
I've seen it quite frequently and kindof like it because it doesn't introduce any state that could leak out or get mutated from somewhere else. Although the ternary operator doesn't make as much sense in python as in other languages since there is no const keyword, otherwise that's what the ternary operator is usually used for.
I've only ever seen it non-nested.
Putting the String issue aside, I just wanted to show the beauty of pattern matching. for i in range(1i, 101) { match (i % 3, i % 5) { (0, 0) => println!("Fizzbuzz"), (0, _) => println!("Fizz"), (_, 0) => println!("Buzz"), _ => println!("{}", i), } } -- edited: removed `.to_string()`, thanks chrismorgan
I haven't looked too deeply into Rust yet, but was able to understand this coming from Elixir. Pattern matching makes for a beautiful solution. This is a similar solution in Elixir: fizzbuzz = fn(x) -> case {rem(x, 3) == 0, rem(x, 5) == 0} do {true, false} -> IO.puts "fizz" {false, true} -> IO.puts "buzz" {true, true} -> IO.puts "fizzbuzz" _ -> IO.puts x end end Enum.each Range.new(1, num), fizzbuzz Since functions a…
defmodule FizzBuzz do
def fizzbuzz(x), do: fizzbuzz(x, {rem(x, 3), rem(x, 5)})
def fizzbuzz(_x, {0, 0}), do: IO.puts "fizzbuzz"
def fizzbuzz(_x, {0, _}), do: IO.puts "fizz"
def fizzbuzz(_x, {_, 0}), do: IO.puts "buzz"
def fizzbuzz(x, {_, _}), do: IO.puts x
end
Enum.each Range.new(1, 100), &FizzBuzz.fizzbuzz/1
(1..100) |> Enum.each fn(x) ->
cond do
rem(x, 3) == 0 and rem(x, 5) == 0 ->
IO.puts "fizzbuzz"
rem(x,5) == 0 ->
IO.puts "buzz"
rem(x,3) == 0 ->
IO.puts "fizz"
true ->
IO.puts x
end
endfor i in range(1, 101): print('FizzBuzz' if i % 15 == 0 else 'Buzz' if i % 5 == 0 else 'Fizz' if i % 3 == 0 else i) python doesn't have expressions? oh dear me.
I think that "{true} if {cond} else {false}" is quite an unnatural and confusing construct, especially when you attempt to nest them. Although I'm not really familiar with Python I thought that was concatenating 'FizzBuzz' with the value of some nested ternary expression and only realised the order was inverted when I tried to parse the inner one. The vast majority of conditionals in languages I know follow the {cond…
for i in range(1, 101): print('FizzBuzz' if i % 15 == 0 else 'Buzz' if i % 5 == 0 else 'Fizz' if i % 3 == 0 else i) python doesn't have expressions? oh dear me.
for i in range(1, 101): print('FizzBuzz' if i % 15 == 0 else 'Buzz' if i % 5 == 0 else 'Fizz' if i % 3 == 0 else i) python doesn't have expressions? oh dear me.
[deleted]