Re: Proposal: Symbol.templateTag

As promised (to myself!) I've written a stage-0. https://github.com/alex-weej/es-symbol-template-tag Your feedback is greatly appreciated. Thanks On 18 November 2016 at 00:30, Alexander Jones wrote: > OK, I was thinking about this incorrectly and I think you're right - it >

Re: Proposal: Symbol.templateTag

fix: forgot of course i would never be 0 `const dsl = (chunks, ...rest) => chunks.reduce((s, c, i) => s + rest[i-1] + c);` VS `const dsl = (chunks, ...rest) => chunks.reduce((s, c, i) => s + (dsl[Symbol.templateTag] || String)(rest[i-1]) + c);` On Fri, Nov 18, 2016 at 12:56 AM, Andrea

Re: Proposal: Symbol.templateTag

I'm not fully sure I understand ... instead of: ```js const dsl = (chunks, ...rest) => chunks.reduce((s, c, i) => s + (i ? rest[i-1] : '') + c); ``` you are looking for something similar ? ```js const dsl = (chunks, ...rest) => chunks.reduce((s, c, i) => s + ( i ? (dsl[Symbol.templateTag] ||

Re: Proposal: Symbol.templateTag

OK, I was thinking about this incorrectly and I think you're right - it doesn't Break The Web. It's exactly the same as when @@isConcatSpreadable and @@toStringTag were introduced, as far as I can tell. If no-one has any obvious objections to save me the effort, I'll try to write up a stage 0

Re: Proposal: Symbol.templateTag

Hi Alexander, I have run into this myself. It is a real problem, and I like the nature of your proposed solution. But I don't understand how it might break the web. If Symbol.templateTag is a new symbol, guaranteed unequal to any prior value, how can introducing it, and new behavior conditional on

Proposal: Symbol.templateTag

Hi es-discuss! Template tags are a great feature with many novel applications, IMO approaching macro-level expressiveness. But due to their nature in this context, it's helpful if tags are named quite tersely. Unfortunately, if you have existing API, this can be challenging. Let's say I have a