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 res
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 warnin
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 ev
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.
Niko
On 7/24/12 6:56 PM, Tim Chevalier wrote:
On Tue, Jul 24, 2012 at 6:55 PM, Niko Matsakis wrote:
Patrick, how hard would
On Tue, Jul 24, 2012 at 6:55 PM, Niko Matsakis 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 an enum. We
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 modul
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"}
