Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce import statements #1469

Merged
merged 42 commits into from
May 28, 2024
Merged

Conversation

sezna
Copy link
Contributor

@sezna sezna commented May 3, 2024

This PR introduces specific item imports, as opposed to our previous open-style imports which just glob-import an entire namespace.

For example:

import Foo.Bar;
import Foo.{Baz, Quux};
import Foo.{Bar.{Baz, Quux}, Corge as Grault};

@sezna sezna marked this pull request as ready for review May 15, 2024 17:38
@sezna sezna marked this pull request as draft May 20, 2024 17:43
@sezna sezna marked this pull request as ready for review May 21, 2024 21:56
if scope.terms.contains_key(&local_name.name)
|| scope.tys.contains_key(&local_name.name)
{
let err = Error::ImportedDuplicate(local_name.name.to_string(), local_name.span);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where exactly should this error be thrown? I think technically, everything below the first open statement is a duplicate import, but I'm only getting errors for the last two.

open Bar;
import Bar.*;
import Bar.BarOperation;
import Bar.BarOperation;  // name error: imported symbol that already exists in scope
import BarOperation; // name error: imported symbol that already exists in scope

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first two are considered opens or glob imports, and are therefore "general". Item imports are "specific". Shadowing rules tend to prioritize specific over general, so globs are are shadowed by the item imports. That's why the following snippet works:

namespace Foo {
    operation F() : Unit {}
}
namespace Bar {
    operation F() : Unit {}
}
namespace Main {
    open Foo;
    import Bar.F;
    @EntryPoint()
    operation Main() : Unit {
        F()
    } 
}

This follows the behavior of Rust, and makes glob imports a bit more usable IMO. With that context, do you think we should change the behavior here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK if this is intended shadowing behavior!

@sezna sezna merged commit 3c5f6e5 into alex/export-statements May 28, 2024
1 check passed
@sezna sezna deleted the alex/import-statements branch May 28, 2024 18:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants