Почему вместимость среза в Golang нельзя расширить в обратном направлении (влево)?

Question

[Илья]

Почему вместимость среза безвозвратно режется именно с левой стороны?
Например из учебного тура можно понять, если мы срежем изначальный массив/срез с
arr := []int{1, 2, 3, 4, 5}
до
arr = arr[:0] // []
его значения можно будет восстановить до исходного вида
arr = arr[:5] // [1 2 3 4 5]
а вот если мы этот же массив/срез срежем с левой стороны, например
arr = arr[5:] // []
то восстановить его уже нельзя
Чем обуславливается такая механика? Почему бы не сделать обратную индексацию как в Python например?

Answer 1

[Xilian]

Что значит восстановить?

arr = arr[:0] - это аналог arr[0:len(arr)];

arr = arr[5:] - это аналог arr[5:len(arr)];

В первом случае - в срезе все 5 элементов - во втором 1 последний.

Начинайте изучать алгоритмы и типы данных с паскаля или Си - меньше таких вопросов будет.

Comments

[Илья]

Что значит восстановить это вы можете глянуть в словарике, а если проблемы с пониманием контекста это уже серьёзнее чем просто не знать значение слова.
В первом и втором случае в срезе нет ни единого элемента. Разница в том, что после первого преобразования в ссылке информация на срез остается, а во втором нет.
Начинайте изучать алгоритмы и типы данных с паскаля или Си - меньше таких ответов будет.

[Илья]

Вы приводите абстрактные + неточные аналогии, без какого либо объяснения. Вопрос и заключается в том, как устроены срезы в Golang.

[Xilian]

Илья, Возможно у нас разные версии Go стоят. И у меня баг/вас поправлен.

Если использовать создание нового слайса через ":=" тогда ситуация меняется?

[rustler2000]

Там Ivan Sokolov ответил очень хорошо - по устройству среза видно что он может безопасно сдвинуться только в право - ибо вместо начального смещения просто модифицирует указатель.

[Xilian]

rustler2000, В некотором роде - он указал на косяк go компилятора и сборщика мусора. Фактически он проводит некорректную операцию - попытался присвоить что-то объявленому имени новое значение, на что компилятор должен ему выдать предупреждение (go таки ). Хотя косяк из моего коммента понятен - первом случае компилятор забывает сдвинуть границы выделенной памяти - тк сам адрес указателя же не меняется, в первом случае, и неявно сдвигается во втором. Непонятно почему в 1 случае не происходит нарушение доступа к памяти.

[rustler2000]

Xilian,чего косяк? какое имя? в го const нету.

он удивляется - почему len в сторону увеличения адресов до cap поднять можно. а увеличить len и "откатить" указатель нельзя.

[Xilian]

rustler2000,
>> в го const нету.

Там все переменные const.

[rustler2000]

Xilian, твой ответ достоин моего косяка :D