I just uncovered a rather surprising failure of exhaustiveness
checking. There was an enum defined like so in a module A:
enum foo { a, b, c }
and then, in another module B:
import A::{foo, a, b}; // Note: no c!
fn bar(f: foo) {
alt f {
a {a}
b
Patrick, how hard would it be to allow something like:
import A::foo::*
to get all the variants of an enum into scope?
Niko
On 7/24/12 6:50 PM, Niko Matsakis wrote:
I just uncovered a rather surprising failure of exhaustiveness
checking. There was an enum defined like so in a module
On Tue, Jul 24, 2012 at 6:55 PM, Niko Matsakis n...@alum.mit.edu wrote:
Patrick, how hard would it be to allow something like:
import A::foo::*
to get all the variants of an enum into scope?
It used to be that import A::foo; *would* get all the variants of an
enum into scope, if foo was
On 07/24/2012 07:29 PM, Niko Matsakis wrote:
Yeah, thinking more on it I'm not sure I want it anyhow. It's kind of
magical.
Probably just fixing the bug about warning about unused bindings is the
best thing.
In that example, if A::foo were a module in addition to an enum, would
you import
On 07/24/2012 07:29 PM, Niko Matsakis wrote:
Yeah, thinking more on it I'm not sure I want it anyhow. It's kind of
magical.
Probably just fixing the bug about warning about unused bindings is the
best thing.
Another idea: If we camel-cased variants by convention, then we could
issue a
On 7/24/12 7:53 PM, Patrick Walton wrote:
In that example, if A::foo were a module in addition to an enum, would
you import everything from the module in addition to all the variants?
If so, resolve3 would have to resolve foo in the type namespace as
well as the module namespace in order to
