https://kotlinlang.org logo
#random
Title
a

avolkmann

09/06/2021, 5:31 PM
e

Emil Kantis

09/06/2021, 5:37 PM
Not my cup of tea. Glad Kotlin don't have it 🤷
💯 1
1
t

Tobias Berger

09/06/2021, 9:07 PM
same. I prefer lambdas for side effects. Or use simple wrapper classes for returning multiple values
a

avolkmann

09/07/2021, 9:19 AM
Agreed, I hardly see any situations where out vars are an elegant solution.
Really appreciate how Kotlin can solve many different use cases without introducing new language constructs.
d

darkmoon_uk

09/08/2021, 4:01 AM
I did a fair bit of C# and, on several occasions, would get enticed to use
out
params.. I noticed though, that I always ended up refactoring them out again, because in the long term it never proved to be the simplest/most 'API ergonomic' solution... just an anecdote but there you go.
👍 1
Destructuring might be a valid case e.g. picking out r, g, b, components from colours; but then Kotlin already elegantly provides that from data classes e.g.
val (r,g,b) = Color.fromHex("#FFBBAA")
e

elect

09/08/2021, 9:59 AM
I'd prefer much more
Copy code
int initializeInMethod;
OutArgExample(::initializeInMethod);
y

Youssef Shoaib [MOD]

09/11/2021, 7:32 PM
Maybe actually some nicer syntax for setter methods could be helpful here? because currently the
::initializeInMethod
example won't work because references to local variables aren't allowed yet. I'm thinking either
::variable.setter
could have better inlining, or maybe we could have some special syntax to refer to a setter of a property
e

elect

09/12/2021, 9:40 AM
of course you need to use a non-local variable
however local variable reference are coming sooner or later
j

Jason5lee

09/27/2021, 8:02 AM
It’s a historical product for
TryBlahblah
methods. Nowaday you should just enable nullable check and return null (unfortunately
Result<T, E>
is never easy to implemented because C# type inference is not the best).
2 Views