Func testGen[T any](value T){ switch any(value).(type){

case string:
fmt.Println("Hello string: ", value)
case int:
fmt.Println("Hello int: ", value)
default:
panic("unknown type")
}
}
Глупый пример немного. Но лучшего варианта сейчас узнать какой тип? Его нет да?
То есть по сути дела, мы все еще должны выполнять проверку в рантайме.
И пока нет методов с дженериками. Свои какие то варинты типов мы тоже не можем толком делать.
Опять пытаюсь переписать свою либу.
Но так что бы уже избавится от постоянной прописи int32(value).
Сделать API более читаемый и простой.
В дженериках есть полезная ~.
Идея в том, что бы каждый числовой тип, более четко и с проверкой на ошибки конвертировал в int32.
Например если мы вышли за границы int32, потому что int64.
То мы сообщаем ошибку и выбираем поведение. Допустим в моем случае, кейсе. Даже в теории такое может быть редко.
И я бы вероятно сбрасывал значение на максимально большое в Int32.
Больших чисел практически нет. Но перестраховаться тоже надо.

С другой стороны, я вот думаю, а оно мне надо? Это так сказать не маленькая вещь.

Но мне очень нравится описание типов в духе rust и nim.
В rust краткость. i32,i64 ect.
В ним что то вроде strint.сstring
В go можно будет навелосипедеть.
i32.i64()
Иногда меня чуть чуть раздражает слишком большая простота Go.
В Си есть макросы и препроцессор...Можно и выкрутится где то.

Может у кого есть опыт? Типо делали свою надстройку над типами?
ДА и в целом. Стоит овчинка выделки или нет. По сути в реалиях std я раз по 10-20 конвертировал типы.
Возможно стоит 1 раз только при вызови API. Потому что основные функции которые общаются с Си.
Int32 и float32. И по сути любое объявление переменной это +-
newValue := int32(9)

Вот обьясните насущную проблему необходимости определения типа?

Пока лучше нет, да. https://github.com/golang/go/issues/49206

Методов нет: https://github.com/golang/go/issues/49085

В принципе, их можно сделать с помощью костылей, ввиде самописного Apply(структ, функ(структ), функ(структ)), и я даже делал, и оно type safe, но без -l=4, спавнит аллокации

Да проще ресивер первым аргументом передавать и всё

> T any а зачем там any?

Я могу сказать только на примере своего проекта. И конкретно мои кейсы. 1. У меня есть функция Draw по сути спустя какое то время я пришел к выводу. Что мне часто надо рисовать числа и строки. strconv юзать по 10 раз. Мало дает удовольствия. Особенно в режиме прототипирования. Мы и раньше могли использовать интерфейсы, вопрос в том. Что вокруг них было построить что то, сложнее чем с дженериками. 2. Карта,где ключ интерфейс. число или строка. В моем проекте сейчас используется гофер луа. И по логике которая заложена в Lua мне надо парсить ключи где строка и число. Да если бы это была 1 карта. Я бы мог разделить их на 2. Но внутри таблицы, таблица и.т.д. 3. Увы в Go нет перезагрузки функций. По этому иногда очень хочется сделать интерфейс, пустой и пихать туда данные, а не плодить API. Я этого избегал. Но с джнериками, это проще поддерживать. Нам так же надо переключатся, потому что мы не знаем конкретный тип. 4. Как и был пример выше. Большинство C кода и библиотек это int32 и float32. В go хочется использовать 64 битную архитектуру. По этому A). Почти вся библиотека math это float64. Б). Почти все стандартные средства :=, функции и.т.д. Принимают по дефолту int (который int64) и float64. Следовательно ты постоянно конвертируешь данные. Что бы сделать что-то обобщенное. Надо интерфейс и свитчить типы. Опишу проблему на примере именно поддерживания всего. Когда ты можешь сделать тип, который может быть А или Б. Создать единую функцию. Твой код намного чище и проще потом это масштабировать. Когда у тебя постоянно что то конвертируется. В будущем ты постоянно что то дописываешь. Меняешь...читать сложнее. Это лично мой опыт на основе других ЯП, Где у меня почти дефолтный кейс создать ТИп который может быть str/int, int/float. И я потом не знаю боли. Сейчас я готов попробовать с Go. Навертеть на интерфейсах и посмотреть. Станет лучше или нет.

Все верно, он там не обязателен. Но в будущем я хочу использовать дженерики, пример не стал менять. Хотел узнать можем ли мы как то по другом свитчить типы или нет.

> Идея в том, что бы каждый числовой тип, более четко и с проверкой на ошибки конвертировал в int32. https://go.dev/play/p/RI9eFZ17Z0L?v=gotip

У вас ключевая проблема не в коде, а в вашем отношение к языку. Вы хотите из него php/python/c++ все в одном. Нужно это понимать. Также нужно понимать, что это неверный подход в программирование в целом и в го в частности. Не надо из го делать пхп

я ничего не понял из описания проблемы при чем здесь система типов, дженерики и strconv?

Дженерики помогают удостоверится в типе или пропихнуть тип, на основе другого типа. Что уменьшает возможности выстрелить себе в ногу. Следовательно проще сделать свои кастомные типы. И забыть о тривиальных вещах. Например функцию которая принимает все числа или стринг. Вопрос что в этом деле опыта на Go мало.

А не подойдет вариант, переделать все числа на type INumber interface { i32() int32 i64() int64 } и потом по ходу дела, звать конверторы, которые нужны?

или type Box[T any] struct { value T } type INumber interface { i32() Box[int32] i64() Box[int64] }

upd @re_devel type Num[T any] struct { value T } func (num Num[T]) i32() Num[int32] { // конвертация в i32 return Num[int32]{} } func (num Num[T]) i64() Num[int64] { // конвертация в i64 return Num[int64]{} } func test() { Num[int]{1}.i32().i32().i32().i64().i64() }

Я прекрасно понимаю что Golang делается для Google и подобных компаний. Но я его использую как язык, для создания GUI / Game. Они могут 1001 раз говорить делайте так, но в этих сферах не всегда так работает. Можно сказать ну надо взять другой инструмент. C++? Не очень хочется ходить по минам. Но в целом почти везде есть свои проблемы. Так что надо просто подумать, как решить свои проблемы.

о! этот лейтмотив мне крайне близок. поддерживаю!