Тем времени поезд нововведений от Расса и не думает останавливаться. Вообще это предложение уже высказывалось много раз, но только после прихода дженериков стало понятно, отрицать необходимость подобного больше возможности нет.
Из главного:
- Появлется новый предопределенный идентификатор
zero. В отличии от ключевого слова (типо type) он может быть переопределен в контексте поэтому ваш старый код который использует zero как переменную или метод, продолжит работать и дальше.- Переменные любого типа поддерживают сравнение с
zero.- Переменным имеющим тип всегда можно присвоить
zero. Будут работать конструкции var my Struct = zero или myInt := int(zero) но вот i := zero работать не будет.- Из функций и методов можно возвращать данные с использованием новой конструкции. Например вот так
return zero, zero, err- Сравнение с
zero доступно внутри дженерик функций у которых на типы-параметры стоит констрейнт any. В данный момент это очень большая головная боль для тех кто пишет библиотеки со структурами данных.Фактически
zero это аналог nil только покрывающий вообще все типы.Из главных мотиваторов нового предложения по улучшению языка Кокс выделел две вещи:
- Ему надоело объяснять зачем нужна конструкция
*new(T) и он уверен что мы можем лучше.- Вопрос сравнения с нулевым значением внутри дженерик функций встал особенно остро после принятия
cmp.Or о котором я обязательно расскажу в других сообщениях.На вопрос почему не использовать
_ Рас ответил, что if myVal == _ { … } выглядит неидиоматично. А вот на вопрос почему не расширить nil ответ посложнее - многие потенциальные баги были пойманы на этапе компиляции за счет того, что nil работает только с map/slice/chan/interface/pointer и эту семантику хотелось бы сохранить и в будущем. Из реального примера, Расс приводит ситуацию когда человек написал if(someValue) вместо if(*someValue) в Сишном коде, что привело к значительно потере данных внутри Google (решилось через резервные системы).От себя добавлю - как и в случае с min/max ситуация назрела и перезрела. Особенно остро это ощущается на бизнес логике, где люди что бы не писать
return MySomeRandomStruct{}, err использовали указатели и не понимали к каким следствиям это может привести.func checkForZero(potentialZero MyType) (SomeType, error) {
if val == zero {
return zero, errors.New("is zero")
}
return SomeType(val), zero
}Скоро и в вашем коде…