I was talking about http://smallcultfollowing.com/babysteps/blog/2012/08/24/datasort-refinements/, which essentially introduces structural enums but only for variants belonging to the same named enum.
> * This strikes me as an extreme change to the language, but perhaps my gut is overly conservative. Well, to some extent: it does indeed cause a fundamental change in type inference, since now any finite set of types can be "unified" as a structural enum type. That said, I think this needs to be done anyway in something like Matsakis' proposal, since otherwise you can't pass an x declared as "let mut x = A; if(foo) {x = B;}" to something taking a Enum[A, B] if Enum also has a C case, so it only really changes how frequently the expanded type inference would be used. BTW, it should be allowed to call impl methods, trait methods and access fields that are common to A, B, C on "A | B | C", effectively adding a new "closed" polymorphism system that can be used by just switching a types from Trait to A | B | C if the only possible Trait implementations in that code are A, B, C, with the rest of the code being unchanged. > You have not addressed in your proposal how you would change the match syntax to deal with non-struct variants, such as ~str or int. Scala uses "x: int" to match an int (or type pattern in general) an assign it to x, and "x @ <pattern>" to assign x to something matched by a pattern (since Scala distinguishes between "value" patterns and type patterns). In Rust distinguishing between value and type patterns might not be necessary, so one can probably use the same character for both cases. > Do the tags on the variants need to encode the whole type, and not just which struct it is? They of course need to identify the whole type, and they probably will change numerically depending on generic instantiation if some can unify under some generic instantiations. > And what about the poor user who didn't think about the fact that they might alias each other, and > thought that all the clauses in the code for A | B| S<Y> were disjoint, but in fact they potentially overlap > due to the potential aliasing, and thus the order of the cases in the above is now crucial, yes? Well, the poor user's thought process turns out to be incorrect, since any enum including a naked type parameter is obviously not disjoint in all cases. > -- Another example: Can/should I now just throw seemingly unrelated struct's into a match, in order to > anticipate that the parameters will be instantiated with that struct? Consider the following: Yes: the compiler can potentially emit an error or warning if the match will never match under any generic instantiation. This also allows a form of internal "partial specialization" of functions, where a function can have specialized behavior for some subsets of generic instantiations.
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev