Hello, everybody! I just arrived at this channel s...

# language-proposals

[Eduardo Guerra]

Hello, everybody! I just arrived at this channel so it's possible that someone has already asked this question before. But, I was wondering if anyone else would like to have n-uples in return statements in kotlin(swift style) like this:

func returnMultipleValues() -> (String, Int, Double) {
    return ("Swift Tuple", 12, 3.14)
}

PS. I know how to use lists hahaha, I just think that it would be a lot easier this way

[raulraja]

I'd love this kind of feature too. It probably requires TupleN or a typelevel HList to represent heterogeneous types. Scala dotty includes now HList and HMap for similar reasons. Also while we are at wishing I'd like auto conversions between TupleN and functions args respecting the types. This type of programs can't be represented with regular lists or arrays without loosing type info so they require compiler support to acknowledge there are generic products and sum types, and potentially a restricted number of max args for Java compat. I think Kotlin had Tuple support at some point but not sure why it was retracted beside the naming mentioned here https://discuss.kotlinlang.org/t/tuples-deprecated/787/5

[henrikhorbovyi]

It would be a really cool feature

[Eduardo Guerra]

Exactly! There are lots of alternatives, the one I like the most is

data class TwoThings(val id: String, val number: Int)

fun returnTwoThings(): TwoThings {
    // Complex computation...
    return TwoThings(strId, number)
}

But compared to the swift syntax it's really boilerplate, especially if I'm willing to use this combination only once

[edrd]

You could use Pair and Triple for that:

fun returnTwoThings(): Pair<String, Int> {
  return strId to number
}

Which can then be extracted nicely with destructuring:

val (first, second) = returnTwoThings()

[Eduardo Guerra]

Sure, That's great, but what if I want four elements, in a return statement it may be difficult to happen but if I want to call a function passing four parameters given by another function it is very easy to happen like differentTypes(givesFourElements())

[edrd]

If you need more than 3 elements and is modelling this with tuples, I think there maybe a design problem in your code. It should probably be a data class instead of a generic structure.

[Eduardo Guerra]

As I said before, yes, you could use a data class. I just think it would be nice to have an alternative. But I agree, sometimes it's better to reach for orthogonality in your language rather than convenience. Having too many ways for solve the same problem may be bad. Still, I really enjoy this feature when working with swift.

[kioba]

If you need more than 3 elements … there maybe a design problem in your code.

I used to think the same, later I run into problems over and over where generating a new, short lived data class was bloating the codebase and implementing a generic TupleN solution was the resolution.

I believe there is space for tuples especially areas where we would use them as function arguments.

[Eduardo Guerra]

Do you have this tupleN code available somewhere?I'd be glad to take a look.

[kioba]

I would suggest to use the Arrow Core library which contains a great Tuple implementation.
You can find it here which supports up to 22 arguments:
https://github.com/arrow-kt/arrow-core/blob/master/arrow-core-data/src/main/kotlin/arrow/core/TupleN.kt

There is a Tuple generation script if you are looking for a standalone solution, but I would suggest using the Arrow lib, it contains tremendous amount of helper functions and continuous support in the #arrow channel.
https://github.com/arrow-kt/arrow/tree/master/generator-scripts

[Nir]

a classic example where, IMHO, you want tuples

[Nir]

is zip

[Nir]

python's zip takes N sequences and returns a sequence over N-tuples

[Nir]

kotlin's zip is really anemic by comparison

[Nir]

I think that while it's often the case you want a data class with named fields, in a language with destructuring like Kotlin, it's weird to get rid of tuples completely

[Nir]

That said I would think in most "non-generic" code, a dataclass is better than a 4+-tuple

[alexsullivan114]

I like the idea of arbitrarily large tuples, but I do feel like there's an alternative, super simple solution - just including a bunch of tuple classes (past 3 I guess) in the standard library.

[Nir]

@alexsullivan114 Yep, I'm with you 100%

[Nir]

up until 9 would cover 99.9999% of use cases

[Nir]

the problem though is that there' sstill tons of boilerplate for actually writing out the functions

[Nir]

for example, you still need 9 overloads of zip

[alexsullivan114]

Oh that's a good point.

[Nir]

Believ eit or not but many many languages just suck it up and do this

[Nir]

Scala, Rust, I believe

[alexsullivan114]

Do they solve that problem in Swift? Like is there any type information for "Arbitrary sized tuple"?

[Nir]

I have no idea! That's a good question. Generally, dealing genercally with tuples required variadic generics, which is a very rare feature

[Nir]

based on a quick google search, I see people proposing it for swift, so I'm going to guess "no"

[Nir]

Obviously, in dynamically typed python, you can just itrate over something that's heterogeneously typed, so you don't have that issue, and you don't need to work about expressing the type signature correctly either.

[Nir]

so you can write zip in python, no problem