Comments 7
Второй пример в слайсах:
slice := []unt{0} должно быть slice := []int{0}
chamgeSliceValues(slice) должно быть changeSliceValues(slice)
Когда len = cap - понятно, почему при append добавленные данные не отобразятся в main.
Но если у нас есть запас по cap, то эвакуация данных не должна происходить. И новые элементы должны быть записаны по старому адресу, но почему-то так не происходит
len слайса передается в функцию по значению. То есть все, что происходит с len слайса внутри функции не касается len этого слайса в глобальной области. Хотя это все вроде один и тот же слайс. Зачем оно так неявно? Кто же его знает...
Я только учу Go, но галочку в голове "передавать слайсы в функции только по указателю" уже поставил. Ибо после питона подобные "оттенки серого" способны взорвать мозг.
а Вы потом из функции явно возвращаете новый слайс или мутируете переданный по указателю слайс внутри функции?
Если возвращаете новый, то от указателя можно отказаться, Вы с ним ничего не выиграете. Если же Вы не возвращаете новый, а мутируете старый, то посмотрите точно ли явный возврат не подходит? (спойлер если это не маршалинг/анмаршалинг, то скорее всего подходит)
Если не закрыть канал, цикл никогда не закончится и случится deadlock. Если закрыть — for range успешно завершается и логика программы идёт дальше.
Ох, уж этот оператор range!
Ведь если мы канал закрыли, то при чтении из него должны продолжить получать дефолтное значение, и по идее войти в бесконечный цикл, но получается что как-то под капотом range проверяет второй возвращаемый аргумент и если он false (канал закрыт), то цикл прерывается, так?
Не надо писать самому что-то вроде:for value, ok := range ch {
if !ok {
break
}
fmt.Println(value)
// some logic
}
В примерах со слайсами если создавать слайсы через make то получается другой результат, можете написать почему
Популярные ошибки в Golang и как их избежать