Listing 10-19: Be consistent in creating the two strings

[emreyolcu]

The variables string1 and string2 are created and passed to longest in different ways for no apparent reason. I've made a small change to make Listing 10-19 consistent with the rest of the examples in Section 10.3.

[StefanSalewski]

Hello,

unfortunately I have the strong feeling that your PR is based on some misunderstanding and makes not that much sense.

The reason that we create functions in Rust with slice parameters &str is just that we then can pass owned strings of String type and slices of &str type. And I think the example tried to show that, in conjunction with other stuff to learn, e.g. lifetimes. So that the two parameters for longest() have different type is intended. If understanding the difference of the two string types is your problem, you might consult the official book again, or maybe study other books, e.g. https://rust-for-c-programmers.salewskis.de/ch8/8_5_slices_as_parameters_and_return_types.html#85-slices-as-parameters-and-return-types

If indeed only consistency is your desire: Do you really would like to add additional redundant code just to make it look more consistent? Most programming languages try to avoid too much unneeded code, because we have to type it in, and more importantly, we have to read it whenever we check the code. And Rust is already quite verbose.

Another question might be, why the book examples are using as_str() to pass a owned String as a &str instead of just passing the owned string just as a reference, as in the working example below:

fn main() {
    let string1 = String::from("long string is long");

    {
        //let string2 = String::from("xyz");
        let string2 = "xyz";
        let result = longest(&string1, string2);
        println!("The longest string is {result}");
    }
}

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

[emreyolcu]

And I think the example tried to show that, in conjunction with other stuff to learn, e.g. lifetimes. So that the two parameters for longest() have different type is intended.

I don't see why this would be intended in a section that is about lifetimes and not slices. As it is written right now, the example creates two strings differently, and upon first read I paused to think whether there is any significance to this difference. It turned out after finishing the section that there is no significance, which is also apparent from the fact that the difference is not commented on in the text and that later similar examples stick to a single way of creating and passing the strings.

If indeed only consistency is your desire: Do you really would like to add additional redundant code just to make it look more consistent?

The point here is not consistency for its own sake but improving the quality of writing.

[StefanSalewski]

Well, the book maintainers or maybe the original authors will decide if accepting your PR.

I strongly assume that the original authors had their reason to write it the way it is. You are right that the two string forms are not the core topic of that section, but it can make sense to repeat some topics from earlier chapters. (I assume the two string forms have been introduced earlier? If not, that would be indeed a bug.) But well, I am from Germany, I can imagine that teaching strategy is different in other countries, e.g. in some Asian or African nations.

I paused to think whether there is any significance to this difference.

Same for me, when I read it in October 2023. After a few seconds I remembered, that Rust has two string types, and both can be passed to functions with &str parameters. I still wonder a bit why as_str was used, instead of passing the owned String just as a reference, which seems to be more idiomatic today. Maybe it is just a legacy from old Rust days.