It's not clear if it's intended to be extendable, as it inherits from an underscored protocol. I'll add a "?".
I wasn't aware that RangeExpression was supposed to be extended.
I'm 90-95% of the way to just washing my hands of this proposal. I left it before, for the same reason, and the discussion totally died, just as it died each of the several previous times it was proposed. I still think it's an important feature, but at this point people are arguing about it possibly precluding a feature which has no design and may fail to ever materialise. I'm getting demands that I should prove that a design space exists for that nonexistent design (and show a "viable design" for a feature I do not actually think should be part of the language and would vote against in a review).
I will reiterate that I could not find another language which supports exhaustive down-casting.
Forcing all conformances to a sealed protocol to be in the same file as the declaration would be a radical departure from the open/public model we have for classes and take this feature in an entirely different direction, all to support ideas of how that nonexistent design might be implemented.
That's not what I propose, and I do not intend to propose such a design. If that's what you want, you are free to start your own proposal.
It's important that we consider the design space in a comprehensive way for any proposed feature. This can certainly take things in directions that you don't intend, and that can be frustrating if you have strong opinions in a different direction. But ultimately, a proposal should have reasons to support why its choices are most appropriate in light of the alternatives, why it addresses some use cases and not others, etc.
If you're unwilling to engage in a discussion of those alternatives and other use cases and intend only to push through with the design if it is specifically what you want, then I think you've already made up your mind to wash your hands of the whole process. One cannot complain that a design for others' suggestions is nonexistent and simultaneously ask them not to talk about designing it.
It does not matter how loud you beg for answer to your messages, Xiaodi: you have no right pushing Karl in a corner he does not want to engage, and your behavior is on the verge of bullying. I'm calling @forum_admins for a moderator's advice.
The Java team is in the process of implementing both sealed types and records (data classes, case classes) as part of their ergonomics improvements plan (Project Amber). I think lessons can be drawn from how they handle the constraints of improving a language with such strict adherence to backwards compatibility. I've attached a document from one of the architects discussing the current design. The section on sealed types is at the bottom quarter of the document. http://cr.openjdk.java.net/~briangoetz/amber/datum.html
I'm sorry to see you go. You've spearheaded an important topic, but I respect that you're feeling pretty frustrated with the process. I don't mean to suggest that you've been unwilling to engage in the past (far from it!), but you are telling us that you don't wish to engage further.
I have an interest in this topic and believe that the concerns raised by @anandabits need to be discussed even if I don't always agree with them. Nowhere do I make any demands of Karl, whom I respect.
Several times now you have popped up in various threads for the sole purpose of directly admonishing me in public for perceived slights that do not involve you in any way. This is not acceptable behavior and it must stop.
Iām really sorry you feel that way. Hijacking is not my intention and I donāt think that is what is happening. Alternative directions and related features often come up in threads on these forums. They are part of the process and can lead to modified designs and / or future enhancements. Proposal authors are expected to incorporate these discussions into the proposal in some fashion, even if they are relegated to āalternatives consideredā.
In some cases the core team has accepted proposals with modification or requested review of a modified proposal. Often the modification appears in discussion and / or the proposal itself as one of these alternative approaches. Feature space in the language, especially in a narrow corner of it, is limited. These alternatives must be evaluated before a decision is made.
Iām sorry to see you go. I really appreciate your contributions. I know it can be frustrating to engage with people who have different opinions (I have experienced this in some of my own proposals and pitches). I do believe it leads to a better language design in the end though.
In any case, what gets into the language in the end is up to the core team - not proposal authors, discussion participants or reviewers. All the rest of us can do is to help inform their decision.
For the benefit of the rest of the community (as well as you Karl, if you return), I want to reply to a few points.
To declare a sealed class, you put the sealed modifier before the name of the class. A sealed class can have subclasses, but all of them must be declared in the same file as the sealed class itself.
So sealed classes in Kotlin behave exactly in the way I have proposed in this thread.
Furthermore, this was a relaxation of a previous design:
(Before Kotlin 1.1, the rules were even more strict: classes had to be nested inside the declaration of the sealed class).
I am not familiar with the evolution of Kotlin, but I imagine this may have changed because people found this limitation onerous and it was not necessary for the implementation. This is similar to a requirement to explicitly list allowed conformances in the protocol declaration, although that is even worse - it requires redundant information (the conformance is also declared explicitly and therefore types are associated with the protocol in two distinct syntactic locations).
Of course anyone is free to propose whatever they wish. But it does strengthen a proposal to address alternatives and include viable future directions for enhancements that have been suggested.
This direction suffers from a nontrivial drawback as a future direction. If we also have sealed protocols that cannot be exhaustively switched over, the distinction introduced a suffix listing valid conformances is pretty subtle. Can you switch over sealed protocols in this design? The answer is not yes or no, but it depends (on the suffix listing valid conformances). Maybe itās ok, but I would have to hear opinions from more people (including some of the core team) before I would consider it a viable direction in the presence of the currently proposed design for sealed.
Exhaustive switch for protocols faces a very high hurdle already and this kind of subtlety could make the difference between them making it into the language and them not making it in.
The reason I care a lot about this feature is that there have been several times where I have been designing a library and this was exactly the right tool (I gave an example earlier today). I would very much like for there to be a day where I can just use that tool instead of having to figure out a workaround. This has been (and still is) true of quite a few corners of Swiftās type system. Many of these frustrating limitations have been lifted (conditional conformances for example) and every time it happens feels very liberating!
Would be nice to push this topic up somehow.
I don't like the Kotlin's rush on adding new features, but in Swift it often feels too cautious. Sparing a new keyword for years instead of lifting a fundamental limitation of the language leads to more and more code being written with poor design and leaking implementation details. Realizing that we could see such a (rather simple) feature only in Swift 7 or even later is very frustrating.
Yes, well - you have an idea for a useful feature, but others have things on their private wishlists and rather than explain how your design precludes those possible future directions, they start demanding that you produce viable demonstrations of those totally different things.
The result is paralysis. This was a big problem with swift evolution; so many great pitches went nowhere because they got derailed by open-ended "what if we later add this feature that I want?"-style questions. I saw it happen so many times, I knew it was where this thread was heading .
There was a proposal with implementation 4.5 years ago. It was designed to support protocols which only serve as abstract interfaces, and would have fit very well with features such as opaque return types. It got derailed by a demand to also produce a design for exhaustive downcasting and so in the end we got nothing.
If you want to start this up again, I'd suggest making a new thread.
Iām all for simplicity. Sometimes I even feel that Swift is already becoming too complex. But the lack of sealed protocols is such an obvious limitation and which is also easy to lift up, that I barely understand why it has been pushed back for such a long time.
Regardless of oneās opinions about sealed protocols or the pace of Swift evolution, for the sake of past participantsā notifications, please start another thread rather than resurrecting this 4-year-old thread.
.