Стоимость определения структур golang при вызове функции

Question

Я наткнулся на функцию, которая определяет свои собственные типы запросов и ответов.

func doSomething() {

    type request struct {
        resourceID string
    }

    type response struct {
        resourceContents *Data
    }

    request := initializeRequest()
    result := dispatchRequest(request)

    ...
}

Я думаю, что это имеет большое преимущество в документировании структуры запроса и ответа прямо в телефункция.Удобство этого особенно очевидно, когда многие такие функции находятся в одном файле, и все они имеют разные типы для своих структур запросов и ответов: определение типов вне функции означает, что я должен назвать их по-разному.

Однако меня беспокоит стоимость этого: гораздо ли дороже, когда вызов функции объявляет свой тип по сравнению с объявлением этого типа в области действия пакета?

Кроме того, этот подход идиоматичен?

Answer 1

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

---

Тем не менее, я нахожу этот код немного подозрительным:

request := initializeRequest()

Где определено initializeRequest? Он должен знать о типе request, поэтому я предполагаю, что он также является внутренним для функции? В противном случае код не скомпилируется. Эти соображения ограничивают полезность функционально-локальных структур во многих случаях, но если у вас все есть локально, я думаю, что это хорошая практика - максимально скрывать типы.

В более масштабных программах вопрос тестирования также вступит в игру. Как вы тестируете типы и функции, работающие с ними, если они скрыты в области видимости?