Sealed class inheritors in the same file

[erokhins]

Design proposal

[norswap]

This would be a great thing to have.

A question though, with this definition:

package foo
sealed class A
class B: A()

I would import B with import foo.B (not the current import foo.A.B), right?
I think that's the desirable behaviour. In current Kotlin I find the need to do import foo.* then import foo.A.* rather pesky (although I understand why that might be useful).

This is what I like about this proposal: it would let the user choose whether sealed class inheritors are visible at the top-level or not.

[erokhins]

You could use import foo.B or import foo.* in this case. Why do you think, that it is desirable behavior?

[norswap]

Terseness. If you have a Maybe sealed class, you usually don't want to write Maybe.Some and Maybe.None but rather Some and None directly. You can do it but it requires an additional import. And probably part of my frustration on this topic is that IntelliJ handles this in a retarded way: if you write Some, it will offer the import option (even if Maybe is already in scope) and write Maybe.Some. If you want Some on its own, you need to edit the imports manually.

Currently, I just use a private constructor for Maybe instead of a sealed class. But then you lose the when support, etc. A shame, really.

[MarioAriasC]

I have the same problem in funKTionale

import org.funktionale.either.Either.Left
import org.funktionale.either.Either.Right
import org.funktionale.option.Option.None

https://github.com/MarioAriasC/funKTionale/blob/master/src/test/kotlin/org/funktionale/either/EitherTest.kt

[erokhins]

Now I see your point. I'm glad that this proposal will fix it.

[abreslav]

The proposal says:

Proposal: allow top-level subclasses for a top-level sealed class in the same file.

Why not just anywhere in the same file (but not a local class, of course)? I see it in the "Questions" section, but what was the reasoning behind the restriction in the first place?

[abreslav]

So we should collect all classes inside it and, if class A is top-level, collect all classes in the same package.

I can't say I can follow this. Why the same package?

[nhaarman]

Perhaps this issue shouldn't have been closed.

That said, I'd like to see the following to compile:

sealed class A
sealed class B : A()

class C : B()
class D : B()

fun test(a: A): Any {
    return when (a) {
        is C -> ""
        is D -> ""
    }
}

The when expression fails to compile because the compiler thinks it is not exhaustive. Issue KT-10648 covers this, but the only comment from @mglukhikh is that this is questionable.

[erokhins]

Why not just anywhere in the same file (but not a local class, of course)? I see it in the "Questions" section, but what was the reasoning behind the restriction in the first place?

@abreslav Well, there is some not-trivial implementations details(about generation synthetic constructors) which was solved for top-level classes but how do it in general is not clear.

I can't say I can follow this. Why the same package?

Because top-level classes from one file belong to same package.

[sthakor1]

Can someone post an example of inheritance with data class please?

[yole]

@sthakor1 have you checked the official Kotlin documentation? http://kotlinlang.org/docs/reference/sealed-classes.html

[dzharkov]

The feature has been released in Kotlin 1.1, thus I'm closing the KEEP. Do not hesitate to open a YouTrack issue for any additional suggestions.

[Murtowski]

There is still not resolved inheritance.

Why I cannot inherit my sealed class in other file?
I would like to have that feature - if I'm splitting project into architecture layers, a top levels like view want to expand sealed class, but It can't - cannot access private init<>

[udalov]

@GitHubMurt The short answer is that it'd complicate incremental compilation in all build tools because in some cases, the sealed class should be compiled together with all of its subclasses and a build tool must keep track of relation of files to ensure this. It's not impossible though, so if you do need this feature, please report it as a new issue.

[LifeIsStrange]

We really need to have the ability to extend from a sealed class in any file outside of the sealed class declaration file.
The issue seems to already exists https://youtrack.jetbrains.com/issue/KT-13495 and nobody is working on it :/