I believe that refined enums are able to cover most of this proposal motivation. So while they are indeed functionally orthogonal, they are alternatives to each other for the common error handling problem.
Personally I don’t have any problems with explicit error enums, except that without refinement I have to write annoying unnecessary match arms.
I think you misunderstood the intent of this proposal, which is to provide a simple sum type which can be left unnamed (For ease of prototyping or one time use). This proposal doesn’t focus on ergonomics, only on semantics of such sum types. You are proposing an extension the current enum model which does not aid in making enums that won’t be used often. It does help with making enums more robust, but that is an orthogonal concern.
The sixth revision, and the second release candidate, is up. It’s mostly more comprehensive justifications of the design decisions of this pre-RFC.
No, I perfectly understood the intent of this proposal. My point is that with refined enums value of the proposed functionality will drop considerably, which in turn could mean that it will not pull its complexity weight. In other words I believe refined enums should be listed as an alternative in this proposal.
Oh, I see now. Yes, then it should be listed as an alternative.
I think the alternatives section should discuss the macro proposals discussed in the previous rfcs repo threads. If I recall, some provided far better ergonomics than this without altering the compiler nearly so much.
This would actually take more work, as there would have to be compiler groundwork to have some way of corresponding names to type as read off from the type, along with associated syntax bikeshedding, and to go back and look variants up when the variant names come back up.
Doh!
This is an interesting example of communication issue; I've been arguing for a minimal language impact, while you were championing a minimal compiler impact. No wonder we were talking past each other. It may be worth clarifying which kind of minimalism was referred to; maybe both?
I can sympathize with the compiler impact argument, but ultimately the compiler is pretty malleable whereas any feature introduced in the language is there to stay.
This is why I am loathe introducing two features simultaneously -- anonymous enums and anonymous variants -- and would rather that each feature be introduced separately and under different feature flags. From a language perspective, I find the usefulness of anonymous enums much more obvious than the usefulness of anonymous variants:
impl Trait).Especially in case of error-handling, the usecase of this proposal, I would argue that if one has to handle one (or some) case(s) specifically, one better be sure of exactly which case is which. A named variant makes it less error-prone, and less brittle in case of refactoring, and error-handling is really where robustness shines.
I find the idea of restricted enums appealing; especially because it immediately solves a number of unresolved questions of this RFC:
enum, as usual.Do you think you’d have the time to draft a minimal RFC only accounting for it?
Excluding, at first, any idea of implementing traits on specific subsets of variants, or any extraneous feature.
I think this is likely incorrect. It seems to me that what you've proposed here takes more work because it is more different; in particular, you need to change type, pattern, and expression grammars, and then you must also introduce the idea of positional variants. If instead you permit:
type Foo = A | B(String) | C { field: u8 };
// alternatively:
type Foo = enum { A, B(String), C { field: u8 } };
// but the former feels more "structural".
then you can reuse the expression and pattern grammars that already exist; you can also likely reuse the machinery of enums themselves much more (because they work with named variants...).
The impact on the language is also smaller.
Okay, then. I eat my words there. Still, I assert that the way I put it is better, because less groundwork would need to be done to allow generic implementations of a useful subset of anonymous variant types with positional variants than with named variants, which is an important factor because this proposal dispenses with ergonomic conveniences to actually get to implementation easily.
I thin you're going to have to point me towards those macros; a quick sweep of the topics I linked to didn't find it.
Seventh revision, and the third release candidate. I gave the document a good looking, and fixed some lingering mistakes.
Thanks to everyone here that helped me catch all the possible parts that I may have missed here. I’ve sent the RFC up to be pulled. See it here.
Edit: silly me, I intended a pull request, not an issue.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.