expanding comments proposal

Isiah Meadows isiahmeadows at gmail.com
Fri Oct 21 02:03:09 UTC 2016


On Thu, Oct 20, 2016, 21:35 Isiah Meadows <isiahmeadows at gmail.com> wrote:

> 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 sent this earlier than I intended

What I meant was that TC39 unanimously agrees that adding pragmas are a bad
idea, and several feel they're ugly.


> 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/66dbf91c/attachment-0001.html>


More information about the es-discuss mailing list