Ответ на вопрос "Если в функции есть return, обязательно ли она вернет то, что указано в return?" указан с очень странной грубой ошибкой.
В статье говорится: "Но в Go есть интересная особенность: если есть именованный выходной параметр (параметры), то функция вернет последнее его значение, несмотря на то, что написано в return."
Мне не удалось беглым поиском подтвердить, что это хоть когда-то работало так, как описано в статье. Как минимум с версии Go 1.20, если в return явно указаны аргументы, они и будут возвращены. Собственно, если пример кода из статьи запустить в песочнице Go, то мы увидим, что возвращаются указанные значения, а не значения, последними присвоенные именованным переменным: https://go.dev/play/p/QYGTrnKLi5y
Какого же невероятного монстра можно породить, если пытаться засунуть концепты ООП в язык, который специально был создан процедурным, чтобы избежать усложнений и лишних абстракций, которые часто привносят парадигмы ООП. Очень будет грустно если "ведущие эксперты" OTUS будут кому-то прививать "цифровые навыки" описанные в этой статье
А можете рассказать про то, почему выбор пал на этот движок? Как будто бы Go - странный выбор для разработки игр
Безумие )
Но почему так хочется попробовать самому...
Ответ на вопрос "Если в функции есть return, обязательно ли она вернет то, что указано в return?" указан с очень странной грубой ошибкой.
В статье говорится: "Но в Go есть интересная особенность: если есть именованный выходной параметр (параметры), то функция вернет последнее его значение, несмотря на то, что написано в return."
Мне не удалось беглым поиском подтвердить, что это хоть когда-то работало так, как описано в статье. Как минимум с версии Go 1.20, если в return явно указаны аргументы, они и будут возвращены. Собственно, если пример кода из статьи запустить в песочнице Go, то мы увидим, что возвращаются указанные значения, а не значения, последними присвоенные именованным переменным: https://go.dev/play/p/QYGTrnKLi5y
Какого же невероятного монстра можно породить, если пытаться засунуть концепты ООП в язык, который специально был создан процедурным, чтобы избежать усложнений и лишних абстракций, которые часто привносят парадигмы ООП. Очень будет грустно если "ведущие эксперты" OTUS будут кому-то прививать "цифровые навыки" описанные в этой статье