4 ms·
You're welcome to dislike it because it's "impure". Actually, depending on how rigidly you define purity, either both implementations are pure (both return the
by Arnavion 5y ago
You're welcome to dislike it because it's "impure". Actually, depending on how rigidly you define purity, either both implementations are pure (both return the same output for the same input) or both implementations are impure (both modify global state via the implicit global allocator).
But you're mistaken in thinking it's something obvious such that others should agree with you. As I said previously, the reality is that you cannot write a program that lets you differentiate whether String + &str reused the same String or allocated a new one. So your hangup is entirely over the documentation revealing the extra information that it has the efficient implementation, not the inefficient one.
- Dylan16807 5y agoThe entire point of passing in a String, according to the article, is to "force you to be aware that you will have to allocate". But you're saying that an extra hidden allocation doesn't matter and you shouldn't have a "hangup" about it? Trying to follow the same rules as the article seems reasonable to me, not a "hangup".
- Arnavion 5y ago>But you're saying that an extra hidden allocation doesn't matter and you shouldn't have a "hangup" about it? No. I recommend reading the subthread the comment was made in more carefully.
- Dylan16807 5y agoThe comment you replied to was talking both about the negatives of hidden allocations and about purity, so I thought you were addressing both. If you are only talking about purity then okay I have no comment.
- Arnavion 5y ago>The comment you replied to was talking both about the negatives of hidden allocations and about purity That is incorrect. The comment was requesting that `Add::add(String, &str) -> String` should be impled by creating a new String instead of mutating an existing one. My comment pointed out why this request was meaningless.