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
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
