Возврат функцией нескольких переменных

v1, v2 := findLinks()

fmt.Printf(«some: %#[1]v, some1: %#[2]v», v1, v2)


Если через одну переменную, то наверно интерфейс надо городить

Что, в го и кортежей нет? Чего только в этом языке нет!

Больные даже первый комментарий не в состоянии прочитать.

А зачем кортежи, когда есть структуры?

Затем, что кортежи - это не структуры, не?

Ну так это философия данного языка — минимализм. Кортежи можно заменить структурами, значит, кортежи не нужны. А иначе можно докатиться чёрт знает до чего: https://habr.com/ru/article/448466

Пишите на опкодах, минималистичнее некуда, чего уж там.

Минимализм должен быть не в ущерб здравому смыслу и удобству.

Всегда приходится идти на какой-то компромисс. Что толку спорить, ты или принимаешь философию языка или нет — и не программируешь на нём.

Итак, решение проблемы топикстартера:

1. Вернуть копию структуры.

2. Реализовать для неё интерфейс Stringer, чтобы удобнее выводить.

покажи как это реализовать по 1 и 2 пункту

Ну, это уж чересчур :). Go Tour.

Что бы не плодить одноразовые сущности.

Ну так это философия данного языка — минимализм. Кортежи можно заменить структурами, значит, кортежи не нужны.

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

Go Hui

Fixed

Мне более интересно, зачем в такой весь из себя минималистичный язык занесли специальный синтаксис для возврата нескольких переменных? Ведь несколько переменных можно заменить структурами, значит, они не нужны.

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

func main() {
fmt.Printf(«1: %v, 2: %v\n», temp()...)
}

func temp() []interface{} { return []interface{}{1, 2} }


https://stackoverflow.com/questions/52653779/how-to-parse-multiple-returns-in...

кортежи, в общем-то, минималистичнее структур

Да только толку от них мало. Первейшая характеристика кода — читабельность. Даже простейшие кортежи — пары вроде std::pair в C++ и то не очень ей способствуют со своими безликими first и second. А уж кортежи больших размеров и вовсе.

Мне более интересно, зачем в такой весь из себя минималистичный язык занесли специальный синтаксис для возврата нескольких переменных? Ведь несколько переменных можно заменить структурами, значит, они не нужны.

Думаю, главная причина фичи возврата нескольких — желание реализовать возврат из функции типизированной ошибки (исключения не рекомендуются, а качественно обрабатывать ошибки надо). Ошибка не связана с самим результатом (не нужна, если результат ожидаемый, и результат не нужен, если возникла ошибка). А структура должна быть набором логически связанных переменных, иначе неправильный дизайн.

Даже простейшие кортежи — пары вроде std::pair в C++ и то не очень ей способствуют со своими безликими first и second. А уж кортежи больших размеров и вовсе.

А вот если добавить pattern matching, то всё ок. Но это в Go тоже не осилили.

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

При чём тут Option?

В Limbo были кортежи, но не было параметрического полиморфизма. И не было Option.

кортежи - это не структуры, не?

Не. Кортежи это частный вид структуры. Внезапно, да?

Development форум как-то скатился в конкурс тупой и ещё тупее. Или мне кажется?

При чём тут Option?

в rust:

fn divide(numerator: f64, denominator: f64) -> Option<f64> {
    if denominator == 0.0 {
        None
    } else {
        Some(numerator / denominator)
    }
}

в go:

func divide(numerator, denominator float64) (float64, error) {
	if denominator == 0 {
		return 0, errors.New("division by zero")
	}
	return numerator / denominator, nil
}

Ты что-то путаешь.

fn divide(numerator: f64, denominator: f64) -> Option<f64> {
    if denominator == 0.0 {
        None
    } else {
        Some(numerator / denominator)
    }
}

=>

func divide(numerator, denominator float64) *float64 {
	if denominator == 0 {
		return nil
	}
	res := numerator / denominator
	return &res
}

Лишнее разыменование на ровном месте и потенциальное разыменование nil'а не пойми ради чего. Вариант feofan'а куда лучше.

Лишнее разыменование на ровном месте и потенциальное разыменование nil'а не пойми ради чего.

Практически то же самое, что и Optional.

Вариант feofan'а куда лучше.

Только разыменовывание nil'а приведёт к панике в рантайме, а простое игнорирование error'а и использование дефолтного 0 — к чему угодно, порче данных, например.

Практически то же самое, что и Optional.

Ага, за исключением типобезопасности.

Практически то же самое, что и Optional.

Я не уверен, как именно реализован optional в rust. Скорее всего там нет разыменований. Но в варианте go от феофана проверка сводится к раскладыванию значения и error по двум регистрам, сравнению одного из них с 0 и дальнейшей работе с другим. И никаких разыменований. Это сможет соптимизировать даже компилятор go.

а простое игнорирование error'а и использование дефолтного 0 — к чему угодно, порче данных, например.

Ну если ты опасаешься того, что ты будешь сознательно игнорировать ошибки, подставляя _ в качестве второго аргумента, то тебе поможет только ЯП с исключениями, и то catch(...) {} есть везде.

А вот использование паники из go в качестве этого самого исключения явно не лучший вариант.

Пропустить обработку ошибок в go случайно весьма не тривиально.

Ну если ты опасаешься того, что ты будешь сознательно игнорировать ошибки, подставляя _ в качестве второго аргумента, то тебе поможет только ЯП с исключениями, и то catch(...) {} есть везде.

Не обязательно, Optional вполне нормально в данном примере. Только тема не об этом.