Привет. Можете, пожалуйста, мне объяснить, почему я не могу сделать

type assertion на тип, неизвестный во время компиляции?

А зачем? Какая практическая задача стоит?

потому, что никакого другого времени для появления типов не будет. какие есть на момент компиляции - такие и есть, новых не появится

как налить чай в несуществующую кружку?

Чашка существует, но неизвестно, какая.

Я не ввожу новые типы, я к существующему привести из интерфейса не могу.

А что конкретно нужно? Почему такой сценарий? Чем не устраивает использование через интерфейс?

в go все чашки известно, какие

Хорошо. У меня есть чашки разного цвета. Я не знаю в compile time, куда польется чай, но в runtime знаю.

Всё равно пример кода был бы куда более понятным

это стандартная задача для интерфейсов

это как это?

type НеизвестнаяЧашка interface{}

зачем детей плохому учишь?

пытаюсь вытянуть пример кода

Кучей копипасты не устраивает. У меня есть несколько десятков структур с данными. В некоторых из них есть поля, которые во время обработки необходимо отрезать. А в некоторых нет. Можно спрятать это все под интерфейс, а-ля func (t T) Strip() Intf, но тогда на каждую структуру нужно писать отдельную имплементацию, которая будет прям по полям конкретным возвращать. Через рефлексию у меня почти получилось сделать это красиво - но не совсем. Поля, которые нужно отрезать, сделаны отдельной включенной структурой со своим Strip() методом. Но интерфейс он возвращать не может, т.к. потом я не могу сделать assertion к reflect.Type. Потому что это не тип вовсе. А в compile time мне, естественно, не видно, что там за тип окажется. Решил, что Strip() теперь возвращает конкретные типы, обошелся без assertion.

Пример кода займет 10 экранчиков. Если это сжать до 20 строк, то будет не очень понятно, зачем я это делаю.

тогда может быть вы изначально неправильно подходите к решению задачи? Что за задача? Почему вам нужно "отрезать поля" что бы это не значило?

Отрезать - значит, присвоить zero value или аналог. В структурах намешаны поля про бизнес-логику и stateful-детали имплементации, это отражение API. Детали имплементации для проверки валидности бизнес-логики мне необходимо отдельно проверить, там, где это имеет смысл, и выкинуть в помойку, отправив остатки в stateless-историю, которая куски про бизнес логику валидирует.

задача непонятна, это вы скорее про детали имплементации своего подхода объясняете

И тем не менее, не вижу проблемы в том, чтобы руками реализовать Strip для всех структур. Работать это будет быстрее, и код совершенно понятный. Если уж настолько много этих структур, то можно кодогенерацию прикрутить, на крайний случай

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

своего рода man in the middle?

Нет, это просто клиенты с разных сторон. MITM в данном случае - это сервер, который я и тестирую.

каков протокол коммуникации? JSON? XML? Protobuf?

Кодогенерация еще один путь, да.

И JSON, и кастомный бинарный, и gRPC.

т.е. вам нужно получить JSON, обработать его и передать дальше?

Руками - плохо. Из 12 полей очень легко пропустить одно. Когда это 40 раз по 12 полей, становится еще легче. Скорость там не важна, все равно все упрется в IO.

Ну, если очень сильно упрощать.

а зачем тогда структуры? Не легче ли запарсить всё в условный map[string]interface{} и динамично обработать?

А это всё время разные 12 полей? И если результат всё равно JSON, то нельзя просто до него и крутить? Обязательно нужна именно промежуточная обрезанная структура?

Да, вот я об этом же

Я ж свитчится запарюсь на 30 разных видов полей. И тем более, как это изначальную проблему решает? Мне все равно нужно куски будет вырезать.

Это решит проблему "не могу вернуть разные типы". Потому что тип результата будет один

Не, ну в теории, конечно, можно все. Но да, это, условно, разные 30 полей в разных комбинациях по 12. Промежуточная обрезанная структура нужна, ибо у меня не только JSON, я там выше писал. Внутренний протокол должен уметь заворачиваться во что угодно.

не проще ли вырезать куски из условного map[string]interface{}?

а reflect магией не запаритесь? 😅 я не понимаю

вы, коллега, настойчиво рассказываете нам про то решение, которое придумали хотя для вас же полезнее было бы описать задачу

Согласен, но во внутренностях проверки бизнес-логики у меня будет просто нечто абстрактное, что не очень просто будет понять.

Есть некоторая система. К системе подключаются клиенты. Клиенты обмениваются через систему сообщениями по некоторому протоколу. Нужно построить конечный автомат вокруг этой системы, который проверял бы то, что взаимодействие с системой согласуется со спецификацией. Вариантов сериализации API - несколько. Возможных валидных и невалидных взаимодействий с системой - десятки, каждое от двух до 15 состояний. В API примешивается куча деталей в рантайме (а-ля timestamp сообщения), которое на валидность проверить нужно, но на логику это влияет слабо. Стало понятнее, или все еще нет?

дайте minimal viable example