If you haven’t gone through my previous article this post won't make a lot of sense why we should be only destructuring only in the mentioned places. I will highly recommend going through it.
If you're done! then welcome back. So from the above article, you would be clear what are the limitations and risks involved with destructuring. So you might be thing why to even use it, I will say it's not necessary to use it, but there are some areas where they just make sense and are risk-free, so go through these list till the end and I will share a sneaky trick to overcome the problem related of positional destructuring with data classes which could survive even refactoring changes.
Destructuring Collections 🧮
Destructuring in Lambda Receivers 💆🏻♀️
Destructuring in for loop 🔃
Destructuring Pairs 👨👧 or triplets 👨👧👦
Destructuring Data classes 💻
So the main problem destructuring data classes is because of the position of the members, if it would have been structural or named it wouldn’t have been the issue. (Again if you don't know what I'm talking about read my previous article). So I will highly recommend not to destructuring on data class, but ... there is a way around it if you want to,
The whole Idea behind Kotlin's destructuring supports is that it's only positional, So we just need to enforce position to the members of the data class.
To know how we can do that 👁 on the code 👇.
Let me know If I missed something or you have any more tricks like these up your sleeves 🧙🏻♀️. reach me out on
email@example.com or my twitter
That's all fokes 🐰🥕 ! See ya again in next post .. Happy Hacking 💻 .