-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Compiler should error when merging with a default exported declaration #3095
Comments
I think the real error here is that there are multiple declarations for the same name with different modifiers, i.e. the first declaration is That of course raises the question of whether to allow function Foo() {
// ...
}
namespace Foo {
// ...
}
interface Foo {
// ...
}
export default Foo; |
@JsonFreeman and I had the idea of actually making export default function Foo() {
// ...
}
namespace Foo {
// ...
}
interface Foo {
// ...
} equivalent to function Foo() {
// ...
}
namespace Foo {
// ...
}
interface Foo {
// ...
}
export default Foo; Though I haven't had the chance to give it much thought. Overall I'm not completely against erroring since it affords us future flexibility. |
Well my idea was to say that all exports of the local symbol Foo would be visible from the outside as both Foo and default. So like this: export default function Foo() { // visible outside as either default or Foo
// ...
}
export interface Foo { // visible outside as either default or Foo
// ...
}
namespace Foo { // not visible outside
// ...
} However, my idea won't work because we do not emit anything for the interface declaration, even though it would have the runtime effect of exporting the function Foo as Foo. @ahejlsberg I like the principle of your idea, but it is actually not the same as what we do for the 'export' modifier. For example we allow you to do this: function Foo() { }
export interface Foo { } but not this: function Foo() { }
export module Foo {
export var x;
} The rule would be that all declarations of the same name that occupy overlapping declaration spaces need to have the same modifiers. Although actually now that I think about it, we could indeed follow this same pattern for |
So in summary @DanielRosenwasser's initial example would be an error. |
@DanielRosenwasser can you add a blurb for this in breaking changes section. |
@ahejlsberg I think the spec might need to reflect this. |
@DanielRosenwasser please create a new spec issue for this. |
Currently if you have the following file
m1.ts
trying to import
m1.ts
with a default binding will not give you all meanings of the exported entity:Discussed this with @JsonFreeman and @vladima, will try to elaborate more, but this issue should serve as a discussion point for suggestions, since there are certain interesting cases like non-exported uninstantiated namespaces.
The text was updated successfully, but these errors were encountered: