✔️ errors.AsType — типобезопастная замена errors.As ✔️ Тем временем, в 1.26 нас (вероятно) ждет еще одно приятное изменение: дженерики наконец доберутся до пакета errors. Все изменение проще описать тремя строчками кода. В 1.25 у нас вот так: var pe fs.PathError if errors.As(err, &pe) { fmt.Println("Failed at path:", pe.Path) } А в 1.26 можно будет вот так: if pe, ok := errors.AsTypefs.PathError; ok { fmt.Println("Failed at path:", pe.Path) } Вроде и небольшое изменение, но оно ведет, как минимум, к двум положительным вещам: • Зона видимости типизированной ошибки во многих участках у нас теперь будет меньше, а значит меньше захламляется пространство имен и снижается необходимость думать над правильным именем для ошибки. • В отличии от errors.As, который вторым аргументом принимал any, новая функция принимает только тех, кто реализует интерфейс error. Несмотря на то, что у нас есть проверка внутри go vet проверяющая второй аргумент у As, всегда приятнее когда компилятор может самостоятельно поймать ошибку на этапе сборки приложения. Кстати, причина по которой сигнатура текущей функции выглядит как As(err error, target any) bool заключается в том, что указатель на интерфейс и указатель на тип реализующий интерфейс для компилятора две несовместимые конструкции. Иначе говоря, вот такой код func As(err error, target error) bool { panic("unimplemented") } … pe fs.PathError if As(err, &pathError) { fmt.Println("Failed at path:", pathError.Path) } … компиляцию не пройдет. А причина в том, что интерфейсы у нас это отдельная сущность которая существует не только во время компиляции, но и во время выполнения.