Remix clone Hacker News

new | show | ask | jobs Github

	▲	9rx 2 years ago
		> The pragmatically "right" choice is to have some tuple type built-in. Perhaps, but in practice we end up with these ill-conceived languages that support tuples but end up not embracing them. Consider, for example, this Rust function: `fn process_tuples(tuple1: (i32, i32), tuple2: (i32, i32), tuple3: (i32, i32))` If it made the "right" choice a function would only accept a single input value, which could be a tuple: `fn process_tuples(tuples: ((i32, i32), (i32, i32), (i32, i32)))` But maybe that's not actually the "right" choice? What if there is a pragmatic reason for functions to have their own concept for tuples that is outside of a tuple type? I will admit, I would rather work with the former function even if it is theoretically unsound. It does a much better job of communicating intent, in my opinion. And once you accept the theoretical unsoundness of a function having its own tuple concept for input, it naturally follows that it needs to also extend that concept to returns. After all, the most basic function is an identity function. What would be super weird is not being able to write an identity function any time the number of inputs is greater than one. Go needed to allow multiple outputs because functions can accept multiple inputs.