Interface that will only allow defined members on derived classes.

[rangeoshun]

Suggestion

Some modifier for strict interfaces. Meaning that implementing this interface will only allow defined members to be declared as public in derived classes.

interface Coo
{
  bar: string;
}

strict interface Foo extends Coo
{
  bob?: number;
}

Extension regards

Pass.

strict interface Moo extends Foo
{
  pop: string = 'a';
}

Shall not pass. Should throw error: only @strict interfaces may extend @strict interface Foo.

interface Moo extends Foo
{
  pop: string = 'a';
}

Implementation regards

Pass.

class Boo implements Foo
{
  bar: string = 1;
}

Still pass.

class Boo implements Foo
{
  bar: string = '1';
  bob: number = 2;
}

Throw error: boo is not allowed in classes implementing strict class Foo.

class Boo implements Foo
{
  bar: string = '1';
  // This will not be welcomed.. poor boo.. boo who?
  boo: number = 3;
}

[mhegazy]

An interface adding a restriction on a how a class is implemented seems strange.. what other languages do that?

[rangeoshun]

I don't know of any language that would do this I must say.

The point would be to instantly resolve any ambiguity on how a member is called. If you think about coordinates, is it lan or lon? There could be other issues where an implementation may be incorrect but not immediately obvious.

If you could define the public members such manner, that could save time for developers by enforcing certain constraints, but still open for extension in form of another interface and closed for unintended modification.

[mhegazy]

I think you are looking for something like #2000, and a flag to force all inherited members to be marked as override.

[rangeoshun]

Yeah, read the ticket, but that includes indicating overrides on every member of every instance. The main difference tho, correct me if I'm wrong, is that it works for inhereted, but not for members implemented the first time. Because if you implement an interface mulitple times, you'd still get the benefit. Which would be the main point here.

[mhegazy]

but not for members implemented the first time.

not sure i understand what you mean.

Because if you implement an interface multiple times, you'd still get the benefit.

I think this is the normal case, it is unlikely to write an interface and implement it only once.

[rangeoshun]

I meant that the flag you described works only if the class is an extension of another. So this solution would work also if you just implement the interface and does not extend a class.

Or am I wrong here?

[mhegazy]

I would expect TS behavior proposed in #2000, If implemented, would behave the same for interfaces as well as classes.

[mhegazy]

I also should add that we did discuss the proposal in #2000 before in #20724 and did not feel the value added here is worth adding new compexity to the language.

[rangeoshun]

Well, the suggestion #20724, is quite complex, and #2000 only handles methods.

This suggestion on the other hand is far simpler for which I assume would not add too much of an overhead in terms of complexity added to the language itself.

[mhegazy]

I do not think an interface restricting what properties its implementing class can do is a good idea. An interface declares a shape of an API, a class implements that, it is almost always that an implementing class will add additional members, and having that be an error seems wrong.

The suggestion in #2000 can be extended to properties.

As i said earlier, we felt the value added by doing such checks (with override not being the default) is not worth introducing new concepts to the language. The same logic applies to any language suggestion. a new feature adds complexity both to users and maintainers, and if the value does not offset the cost, then we are all better off without the feature.

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.