IDK, maybe I have a brain freez, but I can't figur...

# announcements

[Tomasz Krakowiak]

IDK, maybe I have a brain freez, but I can't figure out how to model it without lower bounds. (The apply method, that takes list and returns new list with modifications applied)

interface ListModification<out E> {
	fun applyTo(target: MutableList<in E>)
	fun <T> apply(target: List<T>) : List<T>
			where E : T
}

[nanodeath]

this is tricky because you're using E in both an in and out position, so I'd imagine has to be invariant.

interface ListModification<E> {
    fun applyTo(target: MutableList<E>)
    fun apply(target: List<E>) : List<E>
}

does this not work for you?

[nanodeath]

dunno you might need to split the interface

[Tomasz Krakowiak]

I don't want to make it invariant, as it does not need to be invariant(semantically).

[nanodeath]

interface ListModification<E> {
    fun applyTo(target: MutableList<E>)
    fun <T : E> apply(target: List<E>) : List<T>
}

?

[nanodeath]

even if E == T, should make the types shake out

[Nir]

you'd have to manually specify T for apply

[Nir]

which probably isn't the API you'd want

[Tomasz Krakowiak]

@MaxAller The ListModification interface may add element to list, so this is invalid, as you would allow T to be String when E is Int.

[Nir]

I guess I don't follow how this is not invariant, semantically

[Tomasz Krakowiak]

Ah, sorry. I noticed you removed variance from Change interface...

[nanodeath]

I guess I'm confused how the apply method's type parameter is related to E

[Tomasz Krakowiak]

But I want to be able to do things like:

object Clear : ListManipulation<Nothing>

[Tomasz Krakowiak]

@Nir It's not invariant, as I do not allow transforming elements in this type hierarchy. So you can add elements, remove them, permutate, copy or any combination of those.

[Nir]

you may have to use unsafe variance, though I'm not yet certain or not whether this is a valid usage

[Nir]

kotlin's immutable data structures collection uses the unsafe variance annotation quite often

[Tomasz Krakowiak]

So, naturally:

fun <T> List<T>.apply(change: ListModification<T>)

(T is contravariant in this case)

[Tomasz Krakowiak]

*

fun <T> List<T>.apply(change: ListModification<T>) : List<T>

[Nir]

yeah, it seems like a similar situation to immutable

[Tomasz Krakowiak]

@Nir I would be fine with using unsafe variance if proven necessary internally in implementation. But not in public API.

[Nir]

if i understand you correctly; pretty sure this is mandatory if you want to achieve the variance and signatures you want

[Nir]

Here's a snippet from Kotlin's immutable collections

[Nir]

public interface PersistentList<out E> : ImmutableList<E>, PersistentCollection<E> {
    /**
     * Returns a new persistent list with the specified [element] appended.
     */
    override fun add(element: @UnsafeVariance E): PersistentList<E>

[Nir]

seems very similar to your issue

[nanodeath]

can confirm, this doesn't quite compile :)

attempt_kt.kt

[Nir]

basically, you say that you're out E but you still have functions, that, by their signatures, could read elements passed by the user, so you need to basically reassure the type system that you pinky swear not to actually read those elements

[Tomasz Krakowiak]

Not sure what you mean exactly by "read".
Check this example:

sealed class MetaChange : ListModification<Nothing> {

        override fun applyTo(target: MutableList<in Nothing>) {
            applyMetaChange(target)
        }

        abstract fun <E> applyMetaChange(target: MutableList<E>)

    }

[Nir]

that said, I'm not sure it's as safe in your case (semantically) as it is in this example

[Tomasz Krakowiak]

data class Swap(
        val aIndex: Int,
        val bIndex: Int
    ) : PermutationChange(), StandardChange {
        override fun <T> applyMetaChange(target: MutableList<T>) {
            val element = target.removeAt(aIndex)
            target.add(bIndex, element)
        }
    }

[Tomasz Krakowiak]

Whatever I can do to mutable list, I should be able to do to a copy of the list.

[Tomasz Krakowiak]

I feel now like the variaince is not complete without lower bounds.

[Tomasz Krakowiak]

Ahh, can't Java it as well. But Scala does support lower bounds and it works fine.

[Tomasz Krakowiak]

https://youtrack.jetbrains.com/issue/KT-209 this is this case. (Analogical to one @Nir posted)

[Nir]

yeah, seems like the analogy is accurate

[Nir]

so a lower bound would give you a way to express this within the type system without throwing unsafe variance at it

[Nir]

There are some other good use cases for lower bounds in the link

[Nir]

Thanks for posting that, I was thinking a bit on whether lower bounds had enough utility before drifting back to work, this is pretty compelling

[Tomasz Krakowiak]

Anyway, thanks for ideas : )

[Nir]

thank you, I learned some stuff 🙂