🤨 proposal: spec: memoization (likely decline)

Тут предлагают добавить новое ключевое слово в язык - memo - которое скажет компилятору, что для каждого варианта аргументов функции нужно запомнить результат. Сама техника (называется мемоизация) довольно популярна для оптимизации рекурсивных вычислений - нам не нужно пересчитывать то, что мы уже высчитали до этого. Простейший пример это вычисление чисел фибоначи.

Однако необходимость подобного на уровне ключевого слова для языка вызывает у меня серьезные сомнения. Во первых, в Go нельзя указать, что функция или метод являются чистыми (другое название — без побочных эффектов. Т.е. результат функции зависит только от входящих данных и ни от каких вещей вроде глобальных переменных или чтения/записи с диска). Во вторых, никто не мешает внутри функции использовать map для хранения связи между входящими аргументами и возвращаемыми данными, и скрыть все в деталях реализации (в отличии от предложенного, где информация о мемоизации появится в сигнатуре функции).

Go Core Team высказала те же опасения. Плюс добавили, что вопрос можно решить через сторонний пакет и дженерик тип, который позволит обобщить все работу по мемоизации (по аналогии как сейчас работает sync.Once и sync.OnceFunc).

Отсюда и вывод: предложение предлагают отклонить. Дали три недели на случай, если у кого-то найдутся серьезные аргументы в пользу принятия данного предложения.

Go Update

🤨 proposal: spec: memoization (likely decline)

Тут предлагают добавить новое ключевое слово в язык - memo - которое скажет компилятору, что для каждого варианта аргументов функции нужно запомнить результат. Сама техника (называется мемоизация) довольно популярна для оптимизации рекурсивных вычислений - нам не нужно пересчитывать то, что мы уже высчитали до этого. Простейший пример это вычисление чисел фибоначи.

Однако необходимость подобного на уровне ключевого слова для языка вызывает у меня серьезные сомнения. Во первых, в Go нельзя указать, что функция или метод являются чистыми (другое название — без побочных эффектов. Т.е. результат функции зависит только от входящих данных и ни от каких вещей вроде глобальных переменных или чтения/записи с диска). Во вторых, никто не мешает внутри функции использовать map для хранения связи между входящими аргументами и возвращаемыми данными, и скрыть все в деталях реализации (в отличии от предложенного, где информация о мемоизации появится в сигнатуре функции).

Go Core Team высказала те же опасения. Плюс добавили, что вопрос можно решить через сторонний пакет и дженерик тип, который позволит обобщить все работу по мемоизации (по аналогии как сейчас работает sync.Once и sync.OnceFunc).

Отсюда и вывод: предложение предлагают отклонить. Дали три недели на случай, если у кого-то найдутся серьезные аргументы в пользу принятия данного предложения.

GitHub

proposal: spec: memoization · Issue #62637 · golang/go

Author background Would you consider yourself a novice, intermediate, or experienced Go programmer? Experienced (working professionally with Go). What other languages do you have experience with? R...

hottg.com/go_update/39

2.3K viewsedited  Oct 6, 2023 at 10:07