Stijn de Witt

@silkentrance I hear reasonable concerns voiced here on a proposal that is still WIP...This issue ranks high in Google when searching for info related to this... So please don't close...

@isiahmeadows Your response is more or less describing _how it works now_, however I was describing how _I would expect it to work_. Based on my experience with other languages...

@silkentrance @lukescott @isiahmeadows @alexbyk @jayphelps Would you guys support this proposal?

@isiahmeadows Can you enlighten me on how using `call` in this way conflicts with `Function.prototype.call`? It's not like we are overriding `.call` on _every_ function. Note that we can already...

@isiahmeadows Yes the way your example transpiles is exactly what I had in mind. About the TypeScript compatibility I have to admit I never though about it, because I've never...

@isiahmeadows Those are some cool ideas. I have nothing against using a symbol. I just did not see any need for it. It seems like a relatively small change. As...

@isiahmeadows > And no, this symbol doesn't yet exist in anything stage 1 That explains why I can't find it! :) I assumed it existed because of @lukescott 's comment...

@isiahmeadows You have won me over. I especially like the fact that Symbol.call does not yet exist. We could have a debate on what the best symbol name would be...

@isiahmeadows I updated this proposal to reflect your remarks on using a well-known symbol i.s.o. overriding the `call` method of the function.

@silkentrance > introducing a new Symbol.decoratorCall is not very different and requires both the engine and the transpilers to be aware of such a built-in Symbol.decoratorCall. True. This is why...