Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
I missed to speak about
Person::greet
. No more sentences, just code:Full code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6f5a936cd0482aceb70bb839fceb433c
EDIT: I would have optimized by implementing
std::fmt::Display
.I just applied most of my suggestions to made them more clear. I also missed detail about using standard traits. It offers you a lot of advantage thank to generic implementation, you benefit from other traits that have generic implemention over implemented traits.
For example by implementing
std::default:Default
, you are able to create defaultstd::option::Option
.Such
std::convert::TryFrom
would be better thanstd::str::FromStr
!If this is just a "macro-to-function" transformation, you will surely be able to do.
Sorry, long time I haven't post on Codewars. I was just hoping auto-detection due to context and content (just as most services do)
&str
are slices (looks like a "partial" burrow over piece of data). They avoid memory duplication & ownership. It also lets you abstract over&'static str
andString
burrows.As it was specified: two-way alternatives. To be honest, you should be able to directly pattern match over the array
names
.Here we go:
```rust <code> ```
&str
and when you usedif
.createPerson
avoid creating a "default" instance that NEVER be used.&str
) constructorif
are expressions, use it :)if
may alternate on constructor parameters that each calling constructorC++:
the simple tests succeed, but when I press the 'attempt' button I get this error:
(@-@')
This comment is hidden because it contains spoiler information about the solution
I guess because isize has half of the range of a usize for n>0, so you should avoid an integer overflow when the input is 100.