4 ms·

From the example on their home page: ...no unnecessary allocation occurs. The result of longer_of is a projection of the longer argument, so the mutatio

From the example on their home page: ...no unnecessary allocation occurs. The result of *longer_of* is a projection of the longer argument, so the mutation of z by *emphasize* occurs directly on the value of y. The value is neither copied, nor moved, and yet it is not being passed by reference to emphasize I'm not sure how to read this. A string arg is supplied to a function and a character is (or characters are) appended to it. How can this happen without a new copy of y, since that string must have had an initial lengh (and therefore, a specific place and size on the stack)? Do they create strings with extra padding at the end, just in case someone might append to them? (If so, how much padding and why isn't that generally less efficient overall?) Edit: I didn't realize that asterisk bolding didn't work in quotes. Decided to leave it in anyway.

pmulard 3y ago
There's more of an explanation further down: To better understand, notice that longer_of is not a function; it’s a subscript. A subscript does not return a value, it projects one, granting the caller temporary read and/or write access to it. I'm not really sure how this doesn't fall under a move? Regarding the string, they could also place it on the heap to allow for the variable sizing, which is what Rust does.
zupa-hu 3y ago
Just because it is an immutable value doesn’t mean it needs to live on the stack. That said, I was wondering about a similar thing: what if I modify a 1GB string? Is it copy-on-write? I feel like it can be optimized away 99% of the time only to leave you with 1% of cases that result in very-hard-to-find performance degradations.
- ezekiel68 3y ago
  > Just because it is an immutable value doesn’t mean it needs to live on the stack. Right. But the context of the example made me imagine it probably was -- since I would likely reject out-of-hand any new language that always allocated variables on the heap.
mst 3y ago
The four space prefix is for code/monospaced blocks, not really for quotes. Generally on HN people (myself included) seem to use the '> ' tradition for quoting, which the parser doesn't treat specially but works out fine.
- ezekiel68 3y ago
  Ah you're right and I'm not new to HN formatting. Was just late and I forgot.
ezekiel68 3y ago
To answer my own question a couple of days later, I suppose that if they secretly shadow the mutated var name with a new longer value (in this case) on the stack -- perhaps that is what is meant by "a projection". In that case, no new allocation would occur, since the stack is already allocated. I'm not a language or compiler expert, so maybe this terminology is well know in those circles.

From the example on their home page: ...no unnecessary allocation occurs. The result of *longer_of* is a projection of the longer argument, so the mutatio

pmulard 3y ago

There's more of an explanation further down: To better understand, notice that longer_of is not a function; it’s a subscript. A subscript does not return a value, it projects one, granting the caller temporary read and/or write access to it. I'm not really sure how this doesn't fall under a move? Regarding the string, they could also place it on the heap to allow for the variable sizing, which is what Rust does.

zupa-hu 3y ago

Just because it is an immutable value doesn’t mean it needs to live on the stack. That said, I was wondering about a similar thing: what if I modify a 1GB string? Is it copy-on-write? I feel like it can be optimized away 99% of the time only to leave you with 1% of cases that result in very-hard-to-find performance degradations.

ezekiel68 3y ago
> Just because it is an immutable value doesn’t mean it needs to live on the stack. Right. But the context of the example made me imagine it probably was -- since I would likely reject out-of-hand any new language that always allocated variables on the heap.

mst 3y ago

The four space prefix is for code/monospaced blocks, not really for quotes. Generally on HN people (myself included) seem to use the '> ' tradition for quoting, which the parser doesn't treat specially but works out fine.

ezekiel68 3y ago
Ah you're right and I'm not new to HN formatting. Was just late and I forgot.

ezekiel68 3y ago

To answer my own question a couple of days later, I suppose that if they secretly shadow the mutated var name with a new longer value (in this case) on the stack -- perhaps that is what is meant by "a projection". In that case, no new allocation would occur, since the stack is already allocated. I'm not a language or compiler expert, so maybe this terminology is well know in those circles.