SIP-69: Existential containers #101
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
SethTisue
reviewed
Dec 21, 2024
| ``` | ||
|
|
||
| Defining `Polygon` as a type class rather than an abstract class to be inherited allows us to retroactively state that squares are polygons without modifying the definition of `Square`. | ||
| Sticking to subtyping would require the definition of an inneficient and verbose wrapper class. |
There was a problem hiding this comment.
Suggested change
| Sticking to subtyping would require the definition of an inneficient and verbose wrapper class. | |
| Sticking to subtyping would require the definition of an inefficient and verbose wrapper class. |
| Defining `Polygon` as a type class rather than an abstract class to be inherited allows us to retroactively state that squares are polygons without modifying the definition of `Square`. | ||
| Sticking to subtyping would require the definition of an inneficient and verbose wrapper class. | ||
|
|
||
| Alas, type classes offer limited support for type erasure–the eliding of some type information at compile-time. |
There was a problem hiding this comment.
you mean elided at runtime, I think? maybe I misunderstand, but also, I don't know why type erasure is relevant at all?
|
|
||
| ## Proposed solution | ||
|
|
||
| The problems raised above can be worked around if, instead of using generic parameters with a context bound, we use pairs bundling a value with its conformance witness. |
There was a problem hiding this comment.
Suggested change
| The problems raised above can be worked around if, instead of using generic parameters with a context bound, we use pairs bundling a value with its conformance witness. | |
| The problems raised above can be worked around if, instead of using generic parameters with a context bound, we use pairs bundling each value with its conformance witness. |
| xs.maxByOption((a) => a.witness.area(a.value)) | ||
| ``` | ||
|
|
||
| The type `AnyPolygon` conceptually represents a type-erased polygon. |
There was a problem hiding this comment.
Again, I don't understand why we're talking about type erasure here. Maybe it makes sense somehow, but it's not explained sufficiently for me to follow it.
| Save for the implicit addition of `.value` on method selection when the receiver is an instance of `Containing[C]`, this proposal requires no change in the language. | ||
| As a result, it has no backward binary or TASTy compatibility consequences. | ||
|
|
||
| ### Feature Interactions |
There was a problem hiding this comment.
Suggested change
| ### Feature Interactions | |
| ### Feature interactions |
|
|
||
| One problem not addressed by the proposed encoding is the support of multiple type classes to form the interface of a specific container. | ||
| For example, one may desire to create a container of values whose types conform to both `Polygon` _and_ `Show`. | ||
| We have explored possible encodings for such a feature but decided to remove them from this proposal, as support for multiple type classes can most likely be achieved without any additional language change. |
There was a problem hiding this comment.
Is the intent to answer this more fully before the proposal comes to a vote? Or do we expect it to remain an open question until some future iteration after the SIP lands?
| For example, one may desire to create a container of values whose types conform to both `Polygon` _and_ `Show`. | ||
| We have explored possible encodings for such a feature but decided to remove them from this proposal, as support for multiple type classes can most likely be achieved without any additional language change. | ||
|
|
||
| Another open question relates to possible language support for shortening the expression of a container type and/or value. |
There was a problem hiding this comment.
Ditto on whether this might get filled in soon, or it's definitely a "someday" thing?
|
|
||
| ## Related work | ||
|
|
||
| Swift support existential containers. |
There was a problem hiding this comment.
Suggested change
| Swift support existential containers. | |
| Swift supports existential containers. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.