Does Kotlin have a generic wrapper type like this?...

# getting-started

[min]

Does Kotlin have a generic wrapper type like this?

class Wrapper<T>(var wrapped: T)

[Youssef Shoaib [MOD]]

No, but usually you don't need it

[Vampire]

For what would such a generic wrapper be helpful?

[min]

@Vampire I want Maybe<Maybe<T>> so I can tell Nothing and Just Nothing apart. I could have used Wrapper<T?>? if it existed. I just declared my own type.

[Youssef Shoaib [MOD]]

Hmm, kinda reasonable, but I'd just make my own Option type instead:

sealed class Option<out T> {
  val orNull: T? get() = when (this) {
    is Some -> value
    None -> null
  }
}
data class Some<T>(val value: T): Option<T>
data object None: Option<Nothing>

Of course, Arrow already has one!

[min]

@Youssef Shoaib [MOD] I’m focused on building something to ship, so I don’t care much to discuss Clean Code, but I have to note that it’s very reasonable. Option<Option<T>> (as you’ve named it) would let me encode…
• Whether a binding (eg myParam: Option<Option<T>> = None) is not written or is assigned null
• Whether a collection (eg xs.read(i)) has no corresponding element or stores null
Kotlin uses separate sentinels (eg Iterator#hasNext) a lot because null collapses all these disparate cases. Although it needs to be interoperable with Java, so maybe that’s the best it can do. I personally prefer Option<Option<T>> to having to remember to consult whatever other things to ascertain the validity or meaning of a value.

[Youssef Shoaib [MOD]]

Sorry, to be clear, I meant that the Wrapper idea was somewhat reasonable (I don't love it because it's so easy to have Wrapper<String>, which is pointless). Option is very very reasonable to have because of that nesting confusion.
Rich errors would alleviate some of the use cases for Option, but they aren't in Kotlin yet. I can expand more on that if you'd like!

[min]

@Youssef Shoaib [MOD] Oh, I see. That’s fair, although I’m personally of the opinion that ‘you can do something pointless with it’ is not a significant argument against a feature. x.let { it }.let { it }.let { it } is pointless, as is return if (this.isValid()) true else false. Are rich errors an Arrow feature?

[Youssef Shoaib [MOD]]

Rich Errors are a Kotlin proposal. They introduce a limited form of Union types