expanding comments proposal

Isiah Meadows isiahmeadows at gmail.com
Fri Oct 21 01:35:14 UTC 2016


Please, let's not add a new pragma to the language. `"use strict"` was a
hack to enable some sanity while still remaining back-compatible, but it's
not something we should repeat IMHO. (TC39 unanimously

I would, on the other hand, strongly support dropping most of the
restriction in section 16, third paragraph [1] and moving the remaining
bits to Annex B, namely that conforming implementations are not allowed to
report early errors beyond what's specified as such in the spec. (This is
why TypeScript emits code by default even in the presence of static type
errors. It remains a superset this way.) That would make it much easier to
experiment with typed JavaScript at the engine level, and it would give
much more freedom to type checkers.

[1]:
https://tc39.github.io/ecma262/#sec-error-handling-and-language-extensions

On Thu, Oct 20, 2016, 13:38 Gert Cuykens <gert.cuykens at gmail.com> wrote:

Ok, what about a "use strict comments"; solution to prevent web breaking?

On Thu, Oct 20, 2016 at 7:33 PM, Rick Waldron <waldron.rick at gmail.com>
wrote:
> Overloading comments is not likely to be accepted as a new feature; doing
so
> could be dramatically "web breaking".
>
> You may be interested in this:
>
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types
>
>
> Rick
>
> On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens <gert.cuykens at gmail.com>
wrote:
>>
>> Currently there are two ways to make comments `//` and `/**/` in
>> Ecma262. I think if Ecma262 has a broader way of implementing comments
>> it can open up the door for third party type checkers and leave the
>> burden onto others without the need for transpiling.
>>
>> I am looking into how close ES20XX syntax for example compares to
>> typescript syntax. A Ecma262 compiler doesn't need to look at the
>> typings at all, just be smart enough to ignore typings. Is the Ecma262
>> community willing to look at a few syntax notations that a Ecma262
>> parser should ignore?
>>
>> If there is no objection at first look I am going to put in the effort
>> to try to cover a complete syntax that extends `//` and `/**/` so
>> others can use that to implement for example a type checker? Notice
>> that I am not asking for type checking itself, just expanding `//` and
>> `/**/` that makes it possible for others to do for example type
>> checking and maintain a clean syntax look of their code.
>>
>> ## Example ES2015 code
>>
>> ```html
>> <!DOCTYPE html>
>> <html >
>>
>> <head>
>>   <title>Test</title>
>>   <meta http-equiv="X-UA-Compatible" content="IE=edge" />
>>   <meta name="viewport" content="width=device-width,
>> initial-scale=1.0, minimum-scale=1.0" />
>> </head>
>>
>> <body>
>>   <template>
>>     <style>
>>       :host {
>>           display: block;
>>           box-sizing: border-box;
>>           border: 1px solid red;
>>           margin: 13px 0;
>>           padding: 0 17px;
>>       }
>>     </style>
>>     <p>Test <slot></slot></p>
>>   </template>
>>   <script>
>>     class HelloWorld extends HTMLElement {
>>       constructor() {
>>         super()
>>         const t = document.querySelector('template')
>>         const instance = t.content.cloneNode(true)
>>         const shadowRoot = this.attachShadow({ mode: 'open' })
>>         shadowRoot.appendChild(instance)
>>       }
>>     }
>>     customElements.define('hello-world', HelloWorld)
>>   </script>
>>   <hello-world>Hello World</hello-world>
>> </body>
>> </html>
>> ```
>>
>> ## Example typescript code
>>
>> ```html
>> <!DOCTYPE html>
>> <html >
>>
>> <head>
>>   <title>Test</title>
>>   <meta http-equiv="X-UA-Compatible" content="IE=edge" />
>>   <meta name="viewport" content="width=device-width,
>> initial-scale=1.0, minimum-scale=1.0" />
>> </head>
>>
>> <body>
>>   <template>
>>     <style>
>>       :host {
>>           display: block;
>>           box-sizing: border-box;
>>           border: 1px solid red;
>>           margin: 13px 0;
>>           padding: 0 17px;
>>       }
>>     </style>
>>     <p>Test <slot></slot></p>
>>   </template>
>>   <script type="ts/module">
>>     class HelloWorld extends HTMLElement {
>>       constructor() {
>>         super()
>>         const t:type1 = document.querySelector('template')
>>         const instance:type2 = t.content.cloneNode(true)
>>         const shadowRoot:type3 = this.attachShadow({ mode: 'open' })
>>         shadowRoot.appendChild(instance)
>>       }
>>     }
>>     customElements.define('hello-world', HelloWorld)
>>   </script>
>>   <hello-world>Hello World</hello-world>
>> </body>
>> </html>
>> ```
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161021/d4f6d389/attachment.html>


More information about the es-discuss mailing list