Compiler should error when merging with a default exported declaration

[DanielRosenwasser]

Currently if you have the following file m1.ts

export default function Decl() {
    return 0;
}

export interface Decl {
    p1: number;
    p2: number;
}

export namespace Decl {
    export var x = 10;
    export var y = 20;

    interface I {
    }
}

trying to import m1.ts with a default binding will not give you all meanings of the exported entity:

import Entity from "m1"

Entity();

var x: Entity; // error
var y: Entity.I; // error

Entity.x; // error
Entity.y; // error

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.

[ahejlsberg]

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 export default and the other two are just export. We should disallow that, just as we disallow a set of declarations where some are export and others aren't.

That of course raises the question of whether to allow export default with declarations other than class and function. I don't see a good reason to. I think we're better off just recommending you use this pattern:

function Foo() {
   // ...
}
namespace Foo {
   // ...
}
interface Foo {
   // ...
}
export default Foo;

[DanielRosenwasser]

@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.

[JsonFreeman]

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 default. If we do not allow a default and a non-default to have overlapping declaration spaces, then it will work to just export two different symbols for them. Because in this case, you can never use the default export in a position that would have access to meanings from a non-default export, and vice versa.

[JsonFreeman]

So in summary @DanielRosenwasser's initial example would be an error.

[mhegazy]

@DanielRosenwasser can you add a blurb for this in breaking changes section.

[DanielRosenwasser]

@mhegazy done: microsoft/TypeScript-wiki@bd1a80d

[DanielRosenwasser]

@ahejlsberg I think the spec might need to reflect this.

[mhegazy]

@DanielRosenwasser please create a new spec issue for this.