Ability to decorate abstract member function

Search Terms

I search "decorate abstract member" in the issues list, and #20887 has memtioned this issue but closed.

Suggestion

Ability to decorate abstract function and its params.

Use Cases

To implement a retrofit-like http request library with Typescript. Examples from retrofit website:

public interface GitHubService {
  @GET("users/{user}/repos")
  Call<List<Repo>> listRepos(@Path("user") String user);
}

When translate it into Typescript, we need to decorate an abstract class since interface will be erased after compilation. But,

@MyAPI() // Okay, abstract class is decoratable
abstract class GitHubService {
  @GET("users/{user}/repos")  // ERROR: Cannot decorate an abstract class member
  abstract Call<List<Repo>> listRepos(@Path("user") user: string);  // ERROR 
}

To workaround such limitation, we cannot use abstract class, so it turns out to be

@MyAPI() // Okay, abstract class is decoratable
class GitHubService {
  @GET("users/{user}/repos") 
  Call<List<Repo>> listRepos(@Path("user") user: user) {  
    throw new Error('unimplemented');
  } 
}

This is obviousely not elegant.

I think such ability can be implemented without breaks existing valid code.
Decorator function can determin wheter it's decorating an abstract member by check if value of property descriptor is undefined.

function ClassMemberDecorator(prototype: {}, name: string, pd: PropertyDescriptor) {
  if (typeof pd.value === 'undefined') { // we're decorating abstract member
  }
}

function ClassMemberParamDecorator(prototype: {}, name: string, index: number) {
   if (typeof prototype[name] === 'undefiend') { // we're decorating abstract member param
   }
}

Since when targetting ES3, PropertyDescriptor.value is always undefined, this feature shall only be supported when targetting ES5-onward.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

The issue names no files, tests, or entry points; start by reviewing TypeScript's decorator handling and the related discussion in issue #20887. Done means abstract members and their parameters can be decorated for the requested use case without breaking existing valid code.