Will overriding of `equals()` for inline classes be available in the future?

# announcements

[Karlo Lozovina]

Will overriding of equals() for inline classes be available in the future?

[nfrankel]

afaik, inline classes are used for value objects
objects that have no identity per se
what use-case would you implement by overriding equals()?

[Karlo Lozovina]

ATM, I have an inline class that wraps a Double and would like to compare them directly with ==

[Karlo Lozovina]

(compare a Double and an inline class)

[Karlo Lozovina]

I use inlines currently as a bit of an extra type safety (my functions only take inline classes), but inside the functions, i'd like the inline class to behave mostly as the type it wraps

[Karlo Lozovina]

hopefully it makes some sense 🙂

[nfrankel]

it does 🙂
so you’ve sown the seeds of doubt

[nfrankel]

i need to check by myself

[Karlo Lozovina]

For example, you can implement operator fun plus() just fine, so for example I can add Doubles to my inline classes, and get back a Double

[Karlo Lozovina]

(or I can get an inline class as a result of adding Double to it, whatever best fits the usecase)

[nfrankel]

```inline class Foo(val int: Int)

fun main() {
    val foo1 = Foo(1)
    val foo2 = Foo(1)
    println(foo1 == foo2)
}

it works and print true
as i’d expect

[nfrankel]

sorry, misread your question 😅

[nfrankel]

well, i guess you’d need to wrap your double into the inline class
(or provide an extension function that does it)

[Karlo Lozovina]

yup, that works just fine! it's when comparing with the underlying type that's the problem

[nfrankel]

inline class Foo(val int: Int)

fun Int.toFoo() = Foo(this)

fun main() {
    val foo1 = Foo(1)
    val foo2 = 1.toFoo()
    println(foo1 == foo2)
}

[nfrankel]

i’m not sure it’s desirable to compare the inline type and the wrapped type
it would open a can of worms
that’s the main goal of type safety
yes, longs are ints sometimes
and yet...

[Karlo Lozovina]

yeah, it's definitely a trade of: type safety and security vs. convenience...

[nfrankel]

precisely

[nfrankel]

if you want convenience, you can use python 🐍
<<run for cover>>

[Roukanken]

brings out nuke

[Karlo Lozovina]

🤣

[Karlo Lozovina]

gotta say, for me personally Kotlin is approaching Pythons convenience rapidly...

[Karlo Lozovina]

as far as the language goes, it's basically neck and neck... the "environment" and startup time etc is a different story

[Karlo Lozovina]

Python gets a win when it gets to metaprogramming... writing compiler plugins for Kotlin is currently above my pay grade 😄

[nfrankel]

i feel safe to say it here:
imho, python is great for quick-and-dirty
as soon as you value maintainability, you need types
hence kotlin
the problem if you start with python
is that you’ll ship the prototype to production
and you’ll never go back
been there, done that...

[nfrankel]

i’m wondering
what would you need metaprogramming for @Karlo Lozovina?

[Roukanken]

as soon as you value maintainability, you need types

this, as soon as you cross <a few files> or <bunch of ppls read it>, you need types

[Karlo Lozovina]

Metaprogramming comes up pretty regularly for me, luckily Kotlin/Java has reflection, so a lot of it can be done with it without going the compiler plugin route. Past few weeks I've mostly wanted it for parsing embedded languages in strings (regexes, sql, custom DSLs) and generating some code on the basis of that (with verification at compile time)

[Karlo Lozovina]

Mental note: I should probably see what can be done just with annotations ... so far I've avoided going that way

[nfrankel]

@Karlo Lozovina annotations: “this is the way”