mplatvoet
commented
9 years ago The limitation of vargarg or any other sequence type is that it can only be typed as a whole. Thus when combining/zipping/merging promises of different types you have to resort to a more general type. E.g.:
val p1 : Promise<String, Exception> = //...
val p2 : Promise<Integer, Exception> = //...
//function all does actually exist since 0.1.0 but is undocumented
//since I haven't made my mind up about the signature
val combinedP : Promise<List<Any>, Exception> = all<Any, Exception>(p1, p2)To use the values you either have to cast the results of new List or I have introduce get() on the promises treat all more like a latch. get() is one of the considerations of introducing.
It would be interesting whether in the future the Kotlin compiler would be flexible enough to retain types for variable lengths of arguments. There seems to be some groundwork for this with functions in the upcoming M12
For now the Tuples serve a distinct purpose and therefor will stay. Closing this issue since there is no viable alternative yet.
One strength Kotlin really has going for it now is a low number of class/method points which is important in environments like Android where you have a set limit. The cases where you have combine could easily be vararg instead of fixed parameters, with lists of things instead of set individual first, second, third, fourth, etc.
Plus your code becomes littered with variations of all these classes that must be kept in sync.
Simplify, it is really a list of things to combine, so treat it as such instead of hard set parameters and fields. Otherwise your library will go unused in environments such as Android (which may not be important to you, but it is a key driver helping Kotlin thrive right now, so let's all help that continue)