31–40 of 78 posts
Earlier quoted context omitted.
Nitpick: I'm pretty sure that "11..50" should be a "10..50".
Edited, yeah. Off-by-one errors, can't live without em.
https://play.rust-lang.org/?version=nightly&mode=release&edi...
Earlier quoted context omitted.
Speaking of which, coming from Rust (well, when I say it like that it sounds like Rust is the only language I ever used which is of course not true. I think Rust as a first language would be highly unusual still), I enjoyed being able to say Rust code: let foo = if x 50 { 9000 } else { 42 }; And I miss this in Swift. The ternary operator is fine on its own but I’m not a huge fan of nested ternary operators. With a bi…
I dislike the ternary operator in languages like C++. And many languages copy-paste it because they are used to it. I much prefer the more literal and reversed form in Python. Instead of: int salary = isEmployed() ? 2000 : 0 I prefer: int salary = 2000 if isEmployed() else 0
func calculate_tax(income):
return 0 if income I am a C# guy and every time I see modern Rust, C++ or Go syntax I am really surprised by its deviation from the norm (which is interestingly no longer C but a hybrid between JS/Java/C#). I mean why different Rust syntax for closures and functions. || vs ().
On the other hand, the linage is not Java/JS/C# to Rust but C/C++ to Rust. Considering that, it is an improvement.
Earlier quoted context omitted.
I find ternary operators perfectly readable if you split the parts across lines — they map exactly to the conditions and statements in an if-else group. Cond1 // if this ? Result1 // return this : cond2 // else if this ? Result2 // return this : cond3 // else if this ? Result3 // return this : ResultElse // else return this
True, or even: Cond1 // if this ? Result1 // return this : cond2 // else if this ? Result2 // return this : cond3 // else if this ? Result3 // return this : ResultElse // else return this
Now it is official: I like (modern) JavaScript. I am a C# guy and every time I see modern Rust, C++ or Go syntax I am really surprised by its deviation from the norm (which is interestingly no longer C but a hybrid between JS/Java/C#). I mean why different Rust syntax for closures and functions. || vs (). On the other hand, the linage is not Java/JS/C# to Rust but C/C++ to Rust. Considering that, it is an improvement…
Earlier quoted context omitted.
I don't know Rust - but is it possible to write it like this? fn calculate_tax(income: i32) -> i32 { if income on edit: tried to fix formatting but didn't work.
If you wanted to list out cases without having to use `if`, `else if`, you'd idiomatically use match: fn calculate_tax(income: i32) -> i32 { match income { 0..10 => 0, 10..50 => 20, _ => 50, } } See this playground for a couple other alternatives using match too https://play.rust-lang.org/?version=nightly&mode=debug&editi... As others explained, you do need a default case (either an 'else' in your if statement, or an…
Now it is official: I like (modern) JavaScript. I am a C# guy and every time I see modern Rust, C++ or Go syntax I am really surprised by its deviation from the norm (which is interestingly no longer C but a hybrid between JS/Java/C#). I mean why different Rust syntax for closures and functions. || vs (). On the other hand, the linage is not Java/JS/C# to Rust but C/C++ to Rust. Considering that, it is an improvement…
https://blog.appsignal.com/2018/09/04/ruby-magic-closures-in....
Now it is official: I like (modern) JavaScript. I am a C# guy and every time I see modern Rust, C++ or Go syntax I am really surprised by its deviation from the norm (which is interestingly no longer C but a hybrid between JS/Java/C#). I mean why different Rust syntax for closures and functions. || vs (). On the other hand, the linage is not Java/JS/C# to Rust but C/C++ to Rust. Considering that, it is an improvement…
Rust has a philosophy of easy machine and human parsing. ECMAScript-style `(…) => …` requires that you get to the => before you know whether the (…) is a parenthesised expression or function arguments. With `|…| …`, you know you’re dealing with a closure immediately because there’s no unary pipe operator.
Earlier quoted context omitted.
Speaking of which, coming from Rust (well, when I say it like that it sounds like Rust is the only language I ever used which is of course not true. I think Rust as a first language would be highly unusual still), I enjoyed being able to say Rust code: let foo = if x 50 { 9000 } else { 42 }; And I miss this in Swift. The ternary operator is fine on its own but I’m not a huge fan of nested ternary operators. With a bi…
I find ternary operators perfectly readable if you split the parts across lines — they map exactly to the conditions and statements in an if-else group. Cond1 // if this ? Result1 // return this : cond2 // else if this ? Result2 // return this : cond3 // else if this ? Result3 // return this : ResultElse // else return this
firstPossible ? thenThis
: secondPossible ? thenThisOtherThing
: thirdPossible ? thenThisThirdThing
: defaultThing