Thread
#stdlib
    r

    Ruckus

    2 years ago
    Just throwing this out there, does anyone think it would be a good idea to include such a function in std-lib:
    inline infix fun Any?.hash(other: Any?): Int = hashCode() * 31 + other.hashCode()
    It would simplify writing
    hashCode
    functions:
    class ABC<A, B, C>(val a: A, val b: B, val c: C) {
        override fun hashCode() = a hash b hash c
    }
    You could also add some overloads for primitives, but that would quickly explode.
    Burkhard

    Burkhard

    2 years ago
    I like the idea, but I’m not sure if this will be used. In my experience 95% of
    hashCode
    functions I use are from data classes. Also with a good IDE you will just auto generate the
    hashCode
    function in any case.
    r

    Ruckus

    2 years ago
    That's fair (I disagree about the 95%, but that's probably pretty domain specific)
    s

    spand

    2 years ago
    Any particular reason you dont use
    Objects.hash
    ?
    karelpeeters

    karelpeeters

    2 years ago
    Overhead, it creates a temporary array.
    s

    spand

    2 years ago
    I would be surprised if varargs arent heavily optimised on both the jvm and js
    In any case.. I would heavily prefer a global
    hash
    with agressive compiler inline and unroll than another
    Any?
    extension. Just my two cents. Would be shorter to write also
    Your implemention would also box any primitives I think
    r

    Ruckus

    2 years ago
    Yes, thus my first comment
    s

    spand

    2 years ago
    Ah sorry. It was collapsed here.
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    2 years ago
    One more argument for doing this is that data classes are effectively useless for library APIs: https://jakewharton.com/public-api-challenges-in-kotlin/
    Burkhard

    Burkhard

    2 years ago
    You can work around the problem with the
    copy
    function by providing a custom copy function that calls the generated one, you just need to annotate it with
    @Deprecated("", level = DeprecationLevel.HIDDEN)
    . I don’t know a workaround for
    componentN
    except for only adding new properties to the end. That said, I don’t like the fact that kotlin adds
    componentN
    functions to all data classes automatically. Since they aren’t named, they just pose to much of a risk IMO. Especially when the data class is provided by a library.