3 ms·
Is the expectation that you simply won't create a `map[...]expensivetocopyvalue`, but instead always do `map[...]*expensivetocopyvalue`?
by scottlamb 3y ago
Is the expectation that you simply won't create a `map[...]expensivetocopyvalue`, but instead always do `map[...]*expensivetocopyvalue`?
- konart 3y agoNo expectations whatsoever. You can use pointer or a values. It's up to you.
- scottlamb 3y agoThat's silly. Language constructs and APIs are always made with expectations for how they're used, stated or not. You can write code that compiles without understanding and matching those expectations but it probably won't be good code. I'm asking because I think if it were expected that folks used large/expensive-to-copy map values, this construct would return a reference instead of copying. In Rust for example, the std library's "normal" [1] iterators return references. [1] not those returned by into_* or drain.
- deleted 3y ago[deleted]
- morelisp 3y agoReturning references to storage within the map would be a substantial footgun without borrowing.
- scottlamb 3y agoThanks, useful reply. I just realized that myself: https://news.ycombinator.com/item?id=37576558 https://news.ycombinator.com/item?id=37576558 The peer comments along the lines of "the expecation is it does what it does" are not so helpful from a perspective of learning to write code that is in harmony with the language philosophy.
- konart 3y agoHere an example: https://go.dev/play/p/He0lBEYZJ03 https://go.dev/play/p/He0lBEYZJ03 Value is always a copy. Either a copy of a struct (in case of map[T]struct{}) or a copy of a pointer (in case of map[T]*struct{})
- tedunangst 3y agoThe expectation is the compiler does what you tell it? If you want pointers in your map, you can do that too.
- Arnavion 3y agoThey're asking that, if the programmer wants the map to store expensivetocopyvalue semantically but also doesn't want to have iteration generate expensive copies, does the programmer have to change the map to store *expensivetocopyvalue instead? Anyway I believe the answer is that expensivetocopyvalue is not a type that exists in golang, because golang's "copy" operation is always a simple bitwise copy ala C struct copy / Rust's Copy trait, not like C++ copy ctor / Rust's Clone trait that can be arbitrarily expensive.
- morelisp 3y agoIn Go, `expensivetocopyvalue` can still be achieved via an enormous (e.g. multi-KB/MB) structure (which is most literally expensive to copy) or something containing a lot of pointers (which is not really expensive to copy but will start to pressure the GC).
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]