Why does lazy delegation break contracts

Question

Michael de Kaste · Answer

removing lazy from the group correctly applies the non null contract on the list

Joffrey · Answer

When you go through a delegate the compiler cannot be sure that the value of `group` won t change between 2 subsequent calls

mkrussel · Answer

Since the `group` has a non trivial getter it is calling a method on `Lazy` the compiler cannot assume that the same value will be returned on every call

Joffrey · Answer

As a small justification to the above statements you could work around this just like for nullable vars using `let` ```fun main val group List lt String gt by lazy null val result = group let when it isNullOrEmpty gt it else gt emptyList toSet no error here ```

Joffrey · Answer

But honestly in this specific case I believe this should be sufficient ```fun main val group List lt String gt by lazy null val result = group toSet emptySet ```

mkrussel · Answer

Could also use `val result = group toSet orEmpty `

Michael de Kaste · Answer

the original example had multiple lazy lists like so

Michael de Kaste · Answer

which doesn t let lol itself to using let

mkrussel · Answer

`listOfNotNull group group2 group3 firstOrNull toSet orEmpty `

Joffrey · Answer

Then you could maybe build a list of those lists and find the first non null and non empty one with standard collection operations instead of writing a big `when` expression like this For instance ```fun main val group1 List lt String gt by lazy null val group2 List lt String gt by lazy null val group3 List lt String gt by lazy null val geldigePrestaties = listOf group1 group2 group3 firstOrNull it isNullOrEmpty toSet orEmpty ```

Joffrey · Answer

< mkrussel> haha I guess we keep giving similar advice smile although your version here will take the first non null list while OP wants a non empty one as well

mkrussel · Answer

Yeah I missed that

Michael de Kaste · Answer

sadly building a list out of lazy delegations calls the lazy function whilst building the list of

Joffrey · Answer

You could also build a sequence of them instead ```fun main val group1 List lt String gt by lazy null val group2 List lt String gt by lazy null val group3 List lt String gt by lazy null val groups = sequence yield group1 yield group2 yield group3 val geldigePrestaties = groups firstOrNull it isNullOrEmpty toSet orEmpty ```

Michael de Kaste · Answer

That would indeed work

mkrussel · Answer

I also came up with this ``

mkrussel · Answer

``` val geldigePrestaties Set lt String gt = group takeUnless it isNullOrEmpty group2 takeUnless it isNullOrEmpty group3 takeUnless it isNullOrEmpty toSet orEmpty ```

Joffrey · Answer

< mkrussel> which could work but at this point I d either extract the duplicate code into a function or rework the lazy delegate bodies so they return null instead of empty lists if the rest of the program doesn t need this subtle difference

Michael de Kaste · Answer

Thanks for your feedback guys sadly I don t think the solution becomes much cleaner this way I just wish there was a way to convince the compiler that a lazy call is a special delegate where the value doesn t change

Joffrey · Answer

I do prefer a list sequence approach to a `when` based approach here because semantically you re considering these groups as a collection of things that you re searching All branches of the `when` are the same because of the semantics of what you re doing that s why I personally find it cleaner to have this search for a good group apparent as a search through a collection sequence

Joffrey · Answer

So even if the compiler understood `lazy` in a special way which could indeed be nice I would still prefer the sequence approach here

ephemient · Answer

I prefer ```group1 ifEmpty null group2 ifEmpty null group3 ifEmpty null emptyList ```