Я сокращал как мог

Скорее всего, это не вопрос))

В общем, ща

А что-то типа ТЗ

если там код — кидай на пастбин

Есть методы Foo и Bar, принимаюшие массив Option

func Foo(opts ...Option) {}
func Bar(opts ...Option) {}

Есть набор опций:

func A() Option{}
func B() Option{}
func C() Option{}
func X() Option{}

Проблема в том что есть параметр X, который Foo не поддерживает.
Но из-за того что оба метода принимают Option, в Foo можно прокинуть невалидный аргумент.

func Foo(X()) <- ошибка в рантайме
func Bar(X()) <- все ок

Решить проблему можно сделав для каждого метода свой набор параметров FooOption, BarOption

func Foo(opts ...FooOption) {}
func Bar(opts ...BarOption) {}

Но это приведет к куче бойлерплейта и мешанины в названиях параметров, т.к. большинство параметров для обеих функций одинаковые:

func FooA() FooOption{}
func FooB() FooOption{}
func FooC() FooOption{}

func BarA() BarOption{}
func BarB() BarOption{}
func BarC() BarOption{}
func BarX() BarOption{}

Но зато компилер сможет отловить ошибку:

func Foo(BarX()) <- ошибка в compile time
func Bar(BarX()) <- все ок

What's your choice?

игнорировать X ¯\_(ツ)_/¯

а вообще выглядит как неправильный дизайн

Это дизайн API, который писал не я

правильным он от этого не становится

Option - это же интерфейс?

сделайте три типа, универсальный и специализрованные для foo и bar

Как-то так, вроде:

type myFloat64 float64

func (v *myFloat64) MarshalEasyJSON(w *jwriter.Writer) {
  w.RawString(strconv.FormatFloat(float64(v), 'f', -1, 64))
}

я думаю Option это функция

Option это структура, но могу и в интерфейс переписать

type myFloat64 float64

func (v *myFloat64) MarshalEasyJSON(w *jwriter.Writer) {
  w.RawString(strconv.FormatFloat(float64(v), 'f', -1, 64))
}

спасибо!

https://play.golang.org/p/MfEnasVIgmO
Это работает, но выглядит реально стремно

Все портит утиная типизация, приходится для Bar-specific интерфейса писать метод-заглушку

Ну да, так и делают

капец😒

Как есть