4 ms·

> We really don't have very many that are this careful about allocation. You're missing the point. I don't think this is being careful about allocation. There

> We really don't have very many that are this careful about allocation. You're missing the point. I don't think this is being careful about allocation. There is potential allocation either way - when your string (or vec) grows, allocation under the hood may be necessary too. Do you see my point? Surely doing the allocation inside "a" isn't better than just allocating a new "c" for explicitness' sake. It may be better for performance's sake, but that's not justification enough for making (+) an impure function as I see it. We could always just write it out as .append(b) or whatever if that's what we wanted.

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 ago
  The 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 ago
      The 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.

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 ago
The 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 ago
    The 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.