`listOf` creates a whole new list Java s `unmodifiableList`

Question

`listOf` creates a whole new list Java s `unmodifiableList` is a very thin wrapper that throws exceptions on trying to modify the contents of the wrapped list

ephemient · Answer

just use `Collections unmodifiableList ` if you re on JVM

Kirill Grouchnikov · Answer

That s not helping me here I m looking explicitly for the Kotlin way

Nir · Answer

unmodifiablelist is honestly pretty hacky if you want a nice kotlin solution I d suggest looking at kotlinx immutable

Nir · Answer

but I m not sure it meets your criteria of being a simple one liner

ephemient · Answer

that s immutable not unmodifiable view

ephemient · Answer

I mean IMO kotlin way would be don t reinvent what you don t have to

Nir · Answer

ah alright didn t realize that unmodifiable list doesn t protect its contents

Arkadii Ivanov · Answer

Don t cast List to MutableList It may not succeed

Nir · Answer

Then I think this is the same as our discussion from the other day right ephemient If you write a new class and use delegation then the cast fails on the latest kotlin bytecode right

Kirill Grouchnikov · Answer

I can t prevent the callers from casting back to `MutableList` That s the whole point here I want a one liner that creates a thin unmodifiable view on the original list If there s no such thing just say that

ephemient · Answer

JVM IR but that isn t fully ready yet

Nir · Answer

< Kirill Grouchnikov> it may not work 100 now the most future proof way I think would be to write a simple one line class via delegation ```class UnmodifiableList lt T gt val list List lt T gt List lt T gt by list ```

Arkadii Ivanov · Answer

There is no such thing in stdlib But listOf can t be cast to MutableList under new IR

Nir · Answer

This actually prevents callers from casting

Arkadii Ivanov · Answer

Also Kotlin playground demonstrates this it won t cast

Nir · Answer

listOf can t be cast either in new IR That s surprising

Nir · Answer

good to know

Kirill Grouchnikov · Answer

`listOf` is too heavyweight as it creates a whole new list and takes up a separate chunk of heap

ephemient · Answer

< Nir> even on the new IR List MutableList has special guards but the common idiom doesn t wrap the iterators so they can still be cast if you assume malicious users

Nir · Answer

I guess it depends how far you want to go in fighting Machiavelli

ephemient · Answer

Arkadii Ivanov · Answer

< Nir> actually I m not sure now need to check

Kirill Grouchnikov · Answer

I always assume malicious users when I m writing library code

Kirill Grouchnikov · Answer

Or not even malicious but rather non compliant for whatever reason

Nir · Answer

< Kirill Grouchnikov> if you use UnmodifiableList above then probably in the next few months as you upgrade Kotlin move to new IR it will prevent the cast from being successful

Nir · Answer

I dunno if you assume that then can t people just break everything using reflection

Kirill Grouchnikov · Answer

That would be highly intentional

ephemient · Answer

if you have Java users then I can understand being defensive about List MutableList because the distinction is not visible to them

Kirill Grouchnikov · Answer

This is evolving into a theoretical discussion that I m not that interested in From what I m reading here the answer to my question is that there is no such one liner thin wrapper right now

ephemient · Answer

however if you are all Kotlin I believe you should not bother an List MutableList cast like reflection is explicitly asking for it

Vampire · Answer

That s not really right Most beginners learn how to cast but not how to do reflection And if they can cast they will even if there would be proper and safer methods for doing the same That s not an assumption but a sad observation

Nir · Answer

For me it s not a matter of knowledge but intent In C++ people often use the protect against murphy not machiavelli which I think is a good adage Protect vs things that people could do by accident typically because it looks a lot like common usage like mutating a list don t try to protect against people doing things deliberately that could break them by their nature

Nir · Answer

Is it even practical possible to write a whole Kotlin library protecting your users against downcasting I think it s impossible to do broadly even in theory

Nir · Answer

I guess you could do it if you never ever return any interfaces or open classes to your users ever if that is actually practical for your library

Zach Klippenstein (he/him) [MOD] · Answer

`object List lt Foo gt by yourListOfFoos ` is one line and hides the underlying type like you want

Vampire · Answer

```fun lt T gt List lt T gt asUnmodifiableList = object List lt T gt by this val unmodifiableList = mutableList asUnmodifiableList ```

ephemient · Answer

note my earlier <http pl kotl in|pl kotl in> yes but that is easy to get around by casting the iterator how far are you willing to defend against

ephemient · Answer

also breaks equality and hashcode and tostring

Vampire · Answer

Well one has to die one death smile

Nir · Answer

< Zach Klippenstein he him MOD > yep that was my suggestion as well and in an earlier thread with ephemient but this doesn t actually work unless you re on the new IR

Nir · Answer

ephemient is the one who pointed this out to me

ephemient · Answer

well it works in that it prevents direct modification but it doesn t prevent the upcast in Kotlin

Zach Klippenstein (he/him) [MOD] · Answer

It prevents the cast for me without IR It s an entirely different type it can t be cast to `MutableList`

Nir · Answer

that was my reasoning as well but ephemient said he tried it and was able to do the cast locally I didn t try only on the playground which is using IR shrug

Zach Klippenstein (he/him) [MOD] · Answer

i just did it locally it definitely doesn t work I don t see how it could `object ` creates a new type and completely unrelated types can t be cast to each other on the JVM Unless we re trying subtly different code

Nir · Answer

hmm I was doing `class foo val x List lt Foo gt List lt Foo gt by x`

Nir · Answer

i e class instead of object

Vampire · Answer

```fun lt T gt List lt T gt asUnmodifiableList = object List lt T gt by this val mutableList = mutableListOf 1 2 3 println mutableList mutableList add 4 println mutableList val unmodifiableList = mutableList asUnmodifiableList println unmodifiableList toList mutableList add 5 println unmodifiableList toList unmodifiableList as MutableList add 6 println unmodifiableList toList ``` ``` 1 2 3 1 2 3 4 1 2 3 4 1 2 3 4 5 java lang ClassCastException Line 0$asUnmodifiableList$1 cannot be cast to kotlin collections MutableList```

ephemient · Answer

yeah fails in Kotlin REPL

ephemient · Answer

but if you actually try to compile it the cast succeeds

Nir · Answer

< ephemient> I m trying it locally and it fails

ephemient · Answer

```fun main object List lt Any gt by emptyList as MutableList lt Any gt ```

ephemient · Answer

Kotlin 1 4 10 here I ll give 1 4 20 a try in a sec

Nir · Answer

I m on 1 4 0 it looks like

Nir · Answer

according to my build gradle anyway

Vampire · Answer

``` 1 2 3 1 2 3 4 1 2 3 4 1 2 3 4 5 Exception in thread main java lang ClassCastException de empic teamcity config FooKt$asUnmodifiableList$1 cannot be cast to kotlin collections MutableList at de empic teamcity config FooKt main Foo kt 14 at de empic teamcity config FooKt main Foo kt ``` From a compiled kt file

Vampire · Answer

1 3 70 actually

ephemient · Answer

hmm I do not know what is up with this shrug

ephemient · Answer

in any case I don t think it s worth it do the whole unmodifiable wrapper right or don t half measures mean you fail in harder to anticipate ways

Nir · Answer

This specifically I don t think is worth it because it gives you almost no real protection

Nir · Answer

But a real `ImmutableList` that defensively copies the constructor or otherwise provides functions where it knows it s safe is well worth it

Nir · Answer

Having a class with a `List` member that gets modified from halfway across your program is very very well within the realm of Murphy

Nir · Answer

I had a bad bug from this in python literally yesterday

Vampire · Answer

Immutable is totally different to unmodifiable vie though

Nir · Answer

Yes agree