3 ms·
It's not clear to me why I would need a "dynamically growable slice". That's not a slice at that point, it's an vector aka ArrayList. If all I need is a slice
by wavemode 2y ago
It's not clear to me why I would need a "dynamically growable slice". That's not a slice at that point, it's an vector aka ArrayList.
If all I need is a slice of memory, I'd rather only have to pass around the two pieces of data (pointer and length) than all three.
- zellyn 2y agoYes. "dynamically growable slice" : "vector" :: "tomato" : "to-mah-to"
- tialaramex 2y agoThe growable array type is an owning container, whereas a slice (in C++ and C# span) is a reference type, it doesn't actually own anything. This type isn't either of those things, it's a hybrid, and Go tries to get away with that because it's a garbage collected language so people don't need to care as much about ownership.
- tialaramex 2y agoI think of this as a failed experiment. Like coal powered cars or when we thought maybe transatlantic travel by airship was the Right Thing. It may be hard to know what'll happen without trying. The growable array type (what you call "vector") is a venerable data type, although it does still have parameters you might reasonable tweak e.g. what's the correct growth factor? Doubling is popular but e.g. Zig chooses new_size = (old_size * 1.5) + 8 and you'll see disagreement about what API should be offered and why - e.g. C++ std::vector has the wrong reservation API But this thing clearly isn't a mistake, it's intentionally a hybrid, and if it had been a huge success maybe everybody else would scramble to copy it.
- slashdev 2y agoIndeed, this is how rust handles it. A mutable String or Vec has all three fields, but the borrowed slice or str has just pointer and length. Go chooses to be simpler by not having those kinds of separations, which also makes it a little less efficient under some circumstances.