Make Bob reply with a static lifetime

[ccouzens]

When implementing Bob, it would be very unusual for his reply to have
anyting but a static lifetime

[coriolinus]

While that's true, what benefit is there in requiring a static lifetime here?

[ccouzens]

@coriolinus to familiarise Rust learners to the static lifetime syntax and the situations it might be used.

But I agree, it's not a large improvement.

I think the 2nd lifetime-elision rule made the signature

fn reply<'a>(message: &'a str) -> &'a str

which will prevent Rust from dropping the message memory until the reply is dropped. It's not going to make much difference within the test suite, but I think it's the correct thing to do.

[coriolinus]

I agree with you about what the unelided computed lifetimes are.

If the point is to decouple the two lifetimes, there are a few options:

• Explicit lifetimes

  fn reply<'message, 'response>(message &'message str) -> &'response str { ... }

  This doesn't lock people into using string literals. However, I suspect that this will only actually compile if the parameterization is bounded: <'message, 'response: 'message>. In that case, we're not actually relaxing any restrictions, so we may as well use the elided form for simplicity.

• Use 'static as suggested. Locks people into the (simple, expected) implementation. Prevents implementations which i.e. load a table of cues and responses from a file.

• Just return an owned String

In my interpretation, the point of the bob exercise is to demonstrate that functions can in fact return an &str under certain circumstances. This rules out the third option. The first option isn't great either because 1. we'd need to write out the signature, so the student wouldn't necessarily learn much from it, and 2. that's a pretty complex signature for a difficulty 1 exercise less than 10% of the way through the track.

However, the penalty associated with option 2 isn't trivial either: we want to encourage people to think in terms of APIs which are minimally restrictive, and 'static is pretty restrictive.

I'm inclined against merging this on the grounds that it imposes an (admittedly rarely encountered) implementation restriction on the students in service of an unnoticeable performance improvement. I am willing to be overridden on this if other maintainers feel strongly. If no further discussion occurs, I will close without merging not sooner than Friday, 25 May.

[ccouzens]

I'm inclined against merging this on the grounds that it imposes an (admittedly rarely encountered) implementation restriction on the students in service of an unnoticeable performance improvement. I am willing to be overridden on this if other maintainers feel strongly. If no further discussion occurs, I will close without merging not sooner than Friday, 25 May.

Fair enough. I'm happy for it to be closed unless someone else pushes for it.

[petertseng]

I remmeber that when we added &'static to hello world, we added an explanatory comment of https://github.com/exercism/rust/blob/master/exercises/hello-world/src/lib.rs#L1 . I wonder if we can/should do differently there.

When we considered whether to add &'static lifetime to an input in #239 , we did not like the restrictiveness... despite the fact that the restrictiveness should be invisible (since all inputs are provided by the test suite anyway)

I do see how adding &'static lifetime to an output would place constraints on the implementation.

I can't currently see myself supporting adding it here, given my current understanding of the relative advantages and disadvantages

For my curiosity, can I ask someone to show me an implementation that has &str that do not live for 'static time? Or perhaps I will try to make one, but it may be contrived.