+1. I like this better than both the proposal and the alternatives downthread. It addresses two concerns of mine:
inoutas a muddled metaphor when we’re not talking about functionsborrowas an overloaded term when used as the term for both the action on a value (i.e. in an expression) and the behavior of a variable (i.e. in a declaration)
I also think that grid is the best, most concise casual explanation of these concepts I’ve seen. Even sort of mostly understanding these terms, I still find this helpful! It’s something I’d draw on a whiteboard any time I’m teaching these concepts.
I don’t think any terminology schema I’ve heard, including this one, makes the concept completely transparent to someone encountering it for the first time — but this alternative comes closest of the options I’ve seen to Swift’s ideal of progressive disclosure. And for the experts, I like how the terms roll off the tongue in context as I try sample sentences in my head, discussing things to a hypothetical colleague or student:
- “A borrowing variable would improve performance here”
- “Oops,
var x = things[i]just meansxis itself mutable; we need a mutating variable to modify the array itself” - “You can’t own a struct value that somebody else owns, except by making a copy. If you want to avoid the copy, you’ll need to borrow the value….” (Aside: Does this line of explanation lead to an incorrect conclusion? I think
borrowwill still induce copies in some situations…?)