обидная оплошность have (string, string, []string...) want (string, ...interface {})

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

ну это - да, но от этого я избавился, создав срез интерфейсов и собрав все данные в него и передав его с распаковкой в виде параметра функции, но это конечно странно

что функция которая может принять огромное кол-во параметров не может принять x, y...

думаю что кейс-то распространенный, почему разработчики не продумали его, не понятно

да, через цикл - то давно сделал, но странно что распаковка не работает в интерфейс, а еще странно, что не получается в функцию передать несколько переменных и распаковку

С массивами так.

что функция которая может принять огромное кол-во параметров не может принять x, y...

ага это не страно https://play.golang.org/p/qYsXfXTLc37 раскоменьть 13 строчку удивишься у тебя функчия хочет 2 параметра , а ты передаешь 3 в этом и проблема скорее всего

функция хочет переменное количество аргументов, которое может варьироваться в моем случае от 2 до ~бесконечности, просто все что после 2-ого параметра сворачивается в срез интерфейсов, и не понятно, почему я могу передать функции (x, y, z, a, b, c), но не могу (x, y, z...)

три точки говорит свернуть параметры в срез или развернуть их

потому что сигнатура функции (v1, ...v2) а ты передаешь (v1, v2, ...v3) я попадал на такое преобразуй y, []z в []c и передавай x, c...

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

функция хочет переменное количество аргументов, которое может варьироваться в моем случае от 2 до ~бесконечности, просто все что после 2-ого параметра сворачивается в срез интерфейсов, и не понятно, почему я могу передать функции (x, y, z, a, b, c), но не могу (x, y, z...)

Потому что Гоу автоматически может привести любой тип к интерфесу, но массив интерфейсов это не интерфейс.

массив, не важно чего можно так же в интерфейс привести, иначе бы не возможно было интерфейсы внутри интерфейсов

Это скорее риторический вопрос нежели практический

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

привел итерацией или append ?

эпендом в форе

a := []interface{}{key} for _, v := range timestamps { a = append(a, v) }

здается мне что к []interface{} приводить не обязательно a := []istring{key} a = append(a, timestamps) func(x,a...) должно хватить

неа, он не может стринг развернуть в интерфейс

> cannot use timestamp (type []string) as type []interface {} in argument to

стринг в интерфейс - пожалуйста

и обратно тоже без проблем

но вот с массивами, слайсами и мапами это не работает

вернее - можно превратить слайс в интерфейс

нельзя превратить слайс в слайс интерфейсов

вы об этом тут уже час?

стринг в интерфейс - пожалуйста

https://play.golang.org/p/p32KeNLZ3EC

https://play.golang.org/p/p32KeNLZ3EC

это конвертация слайсов, а не строк

это конвертация слайсов, а не строк

??? разве это не эквивалент: timestamps := []string{"bbb", "ccc", "dddd"} test(timestamps...) test("bbb", "ccc", "dddd")

и ... - это не реальное превращение набора элементов в отдельные параметры, а синтаксический сахар по передаче слайса

и ... - это не реальное превращение набора элементов в отдельные параметры, а синтаксический сахар по передаче слайса

Как обычно, задумка хороша, но реализация подкачала)

??? разве это не эквивалент: timestamps := []string{"bbb", "ccc", "dddd"} test(timestamps...) test("bbb", "ccc", "dddd")

конечно нет test("bbb", "ccc", "dddd") - тут каждая строка отдельно превращается в интерфейс, из них формируется слайс и он уезжает в test

Как обычно, задумка хороша, но реализация подкачала)

Реализация нормальная. Просто внутрь append передается не раздербаненый на элементы массив, а массив целиком как он есть. .

на самом деле - надо смотреть, что там на стек ложится, слайс или элементы по одному

А какой в этом смысл? Когда таким макаром можно спокойно передавать сам слайс и не париться за эти три точки

но с точки зрения синтаксиса можно считать, что слайс

А какой в этом смысл? Когда таким макаром можно спокойно передавать сам слайс и не париться за эти три точки

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

но с точки зрения синтаксиса можно считать, что слайс

https://play.golang.org/p/UDUgnIjHmbW

и?

А какой в этом смысл? Когда таким макаром можно спокойно передавать сам слайс и не париться за эти три точки

Для сохранения единства синтаксиса с другими функциями.

и?

итог одинаковый

а почему должен быть разный?

а почему должен быть разный?

ну так по вашим словам получается что идет приведение слайсов

ну так по вашим словам получается что идет приведение слайсов

Нет приведения слайсов.

ну так по вашим словам получается что идет приведение слайсов

https://play.golang.org/p/Ei-PT1X0Nnq - может так будет понятнее

Ну он же в конечном итоге все равно по элементно разварачивается и ложится в стек, зачем оно перед этим слайс стрингов пытается привести к слайсу интерфейсов? и почему проваливается?

ну так по вашим словам получается что идет приведение слайсов

Представьте себе, что когда вы вставляете в функцию элементы одиночно, то вы фактически разворачиваете цикл вручную. А компилятор сворачивает вставленное вами в слайс.

Ну он же в конечном итоге все равно по элементно разварачивается и ложится в стек, зачем оно перед этим слайс стрингов пытается привести к слайсу интерфейсов? и почему проваливается?

Не кладется он поэлементно.

Ну он же в конечном итоге все равно по элементно разварачивается и ложится в стек, зачем оно перед этим слайс стрингов пытается привести к слайсу интерфейсов? и почему проваливается?

кто сказал, что он разворачивается поэлементно и ложится в стек?

я бы скорее предположил, что формируется слайс и на стек ложится как раз он

это бы объяснило все "странности"

А должно быть наоборот, по сути))))

что кому должно?

А должно быть наоборот, по сути))))

Кто вам сказал, что должно?

Ну ладно, как факт задача давно решена, а это видимо особенность

а если у меня там миллион элементов - надо их все на стек пушить?

Я предполагаю что по задумке должно

зачем же вы это предполагаете?

а если у меня там миллион элементов - надо их все на стек пушить?

Да, а иначе какой смысл? передал слайс и все

еще раз

очень похоже на то, что три точки - только синтаксический сахар для передачи слайса

Да это я уже понял ))))

тогда давайте завязывать

Да, а иначе какой смысл? передал слайс и все

Не все. Троиточие, чтобы показать, что мы хотим передать элеметы массива.

не

ERROR: S client not available

троеточие никакого смысла особенного не имеет

и запросто без него было бы можно обойтись

но - кто-то его нам сделал

Как тогда компилятор в случае интерфейсов будет различать, вставить сам слайс как интерфейс или элементы этого слайса?

Я к тому что в php и питоне есть нормальная распаковка элементов, а в го как оказалось только жалкое подобие, маскирующеееся под это)))

и в перле есть распаковка

вот только зачем она нужна, скажите мне, пожалуйста?

чтобы школоло могло передавать слайсы чего угодно как слайсы пустых интерфейсов?

Как тогда компилятор в случае интерфейсов будет различать, вставить сам слайс как интерфейс или элементы этого слайса?

а там сразу будет жесткий синтаксис. хочешь передать слайс - пиши в определении функции слайс. хочешь параметры - пиши параметры.

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

Если бы разрабы оставили бы там слайс, то не было бы вопросов, но там ...

а там сразу будет жесткий синтаксис. хочешь передать слайс - пиши в определении функции слайс. хочешь параметры - пиши параметры.

И заводить две функции с разными именами.

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

И заводить две функции с разными именами.

зачем? при вызове создаешь из параметров слайс, да и все

зачем? при вызове создаешь из параметров слайс, да и все

Да, вариант.

зачем? при вызове создаешь из параметров слайс, да и все

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

так и реализовано

Тогда вопросов не будет и все будут довольны

их и нет, недовольный только один

так и реализовано

не фига, иначе бы я мог передать функции с (x string, y ... string) и так (x, y, z, a, b, c), и так (x, y, z...)

их и нет, недовольный только один

Да мне по большому счету пофиг, сказал же что это скорее риторический вопрос

не фига, иначе бы я мог передать функции с (x string, y ... string) и так (x, y, z, a, b, c), и так (x, y, z...)

фиксированные сами по себе, то, что описано слайсом - передается как слайс

три точки - оператор описания слайса, а не распаковки-запаковки, как вы почему-то думаете

Ну вот, а я сказал что сначала отсчитываем фиксы, а все остальное упаковываем, вот была бы сказка, вы сказали что так и есть....

фиксы - это то, что в контракте функции указано.

Ладно, закругляемся))))

не фига, иначе бы я мог передать функции с (x string, y ... string) и так (x, y, z, a, b, c), и так (x, y, z...)

нет или (x, y, z, a, b, c) или (x, z...) но не как (x, y, z...) все в сигнатуре описания функции читаем https://golang.org/ref/spec#Passing_arguments_to_..._parameters

нет или (x, y, z, a, b, c) или (x, z...) но не как (x, y, z...) все в сигнатуре описания функции читаем https://golang.org/ref/spec#Passing_arguments_to_..._parameters

Да это понятно, но не логично)

еще как логично

еще как логично

ок

Да это понятно, но не логично)

Не логично только для вас!