Overloading of interface properties having function types is inconsistent between function signature syntaxes

[rotemdan]

interface A 
{
    func(arg: string): boolean;
    func(arg: number): string;
} // OK!

interface B 
{
    func: (arg: string) => boolean;
    func: (arg: number) => string;
} // Error! Duplicate identifier 'func'.

?

[danquirk]

This is by design but it can look confusing. The key is to realize that function overloads are actually just syntax sugar for a single property by that name with the combined types of the overloads. So in your example here, the first interface declaration actually looks like this:

interface A {
   func: { (arg: string): boolean; 
           (arg: number): string; }
}

There is only actually one property named func, but its type is an object with multiple call signatures. This form is perfectly valid to write oneself, but the overload syntax is more familiar and readable to a lot of folks. On the other hand your second declaration is actually declaring 2 properties named func.

[rotemdan]

@danquirk

The expansion you describe looks like a compiler implementation artifact. I don't see a need for programmers to know about this and it shouldn't play a part in their reasoning about the language. There is no difference in practice between the two syntaxes. If that was chosen to be confusing by design, then the design is not great.

Also consider a possible future change to the language, equivalent to expression bodied members introduced in C# 6:

// C#
class A
{
    ...
    public int Multiply(int a, int b) => a * b;
}

// "Distant Future" TypeScript
class A
{
    ...
    multiply = (a: number, b: number) => a * b;
}

It doesn't really matter if it's possible or even desirable to overload with this syntax (I'm not sure if that's currently supported in C# but I can't see a reason why not?). What matters is the fact that it is valid syntax describing a valid function semantically equivalent to what would be implied by the more standard syntax, so overloading would definitely be relevant in this context (whether it would look pretty with = is a different matter altogether and not the issue here). The same goes for interfaces.

[danquirk]

Syntax must be chosen and rules must be assigned. In practice the difference between various syntax forms is whatever the rules are defined to be. What seems like obviously the same to you may be obviously different to someone else. After all, one might reasonably conclude that obviously these two forms are different, because why would the language have 2 different syntax forms for the exact same semantics?

Certainly we could allow the form you describe to be equivalent to the current overload syntax, but like most decisions, this involves trade offs. For one, there's now 2 different but otherwise equivalent syntax forms for the same thing, which many people would say is generally undesirable from a philosophical/pedagogical perspective. More practically, now you need rules for cases like:

interface A {
    // this is ok by your rule
    foo: (x: string) => string;
    foo: (x: number) => number;

    // this is not ok? or should it be equivalent to foo2: string|number? 
    // since why only combine function types if we have semantics to combine other types?
    foo2: string;
    foo2: number;

    // this is ok but I actually made a typo and hoped for an error
    // I meant for the 2nd foo3 to be named foo4, now it's silently coalesced into an overload set
    foo3: (x:string) => string;
    foo3: (x: number) => number;
}

And more, like if A was already defined and already had a foo member, now I don't realize I'm stomping on it/merging with it when I was trying to create a unique property name for my use. We also have to consider how it meshes with variables of function types with overloads, as you would like consistency there.

The current syntax is fairly easy to describe, deterministic, and familiar to (at least) most C family language users. Overloads are written a particular way. If you do not write them that way, you get a (hopefully helpful) error. Rules for convenience which allow mistakes to get 'helpfully' interpreted in some legal way are often a dangerous road to go down (as we're all surely familiar with having spent a lot of time with JavaScript :)).

[rotemdan]

@danquirk

Thanks for the comprehensive answer. I understand the arguments you present and have considered them myself. The original intention of the issue was not necessarily to take a predetermined stand at what should be done, e.g. whether to add an equivalent signature overloading syntax/support for the secondary syntax. I think that since this is a redundant syntax anyway (and apparently the secondary one, though I actually used it exclusively for a while so I assumed overloading in interfaces wasn't even possible!) it wouldn't be very critical at this point to hasten in deciding whether to add additional functionality for it.

I am a bit curious though why was there a secondary syntax in the first place?

To begin answering my own question, I just realized that "expression bodied members" are actually possible in TypeScript :) and I've even used them several times before but seem to have forgotten about it. So I guess that could be a valid reason.. at least to "match" it (for completion). Although in the context of interface implementation by a class it still is interchangeable with the "normal" syntax:

interface A
{
    f(a: number): string
}

class Test implements A
{
    f = (a: number) => "abcd";
} // OK!

Though I don't see it as a problem. Are there any other reasons? (assuming this one is valid, I guess?)

[rotemdan]

I'll try to partially answer my own question again:

There seem to be several uses for interfaces in Typescript. One of them is to model the equivalent of C# or Java interfaces. In this case, a specifier for a function would usually describe a class method:

interface A
{
    func(arg: number): boolean
}

class C implements A
{
    func(arg: number): boolean
    {
        return true;
    }
}

Another one is to model what would be described as "structs" in other languages, where a property assigned a function type would usually model a function that's "carried" by the object (perhaps close to a C# "delegate"), such as a callback:

let a: { callback: (arg: number) => boolean };

a = { callback: (arg) => true };

Using the other syntax in this case would look a bit strange and out-of-place:

let a: { result: string, callback(arg: number): boolean, count: number };

a = { result: "OK", callback: (arg) => true , count: 45};

And of course, to use normal "delegate" types in function bodies etc.:

function test
{
    let func: (arg: number) => boolean;
    func = (arg) => true;
}

Though in this case that wouldn't necessarily imply that syntax must be available in interfaces/classes etc.