Add TC39 January meeting blog post

Author: kborchers

_pages/blog.md

@@ -2,4 +2,3 @@
 title: Blog
 ---
 
-## Coming Soon

_posts/2017-02-06-TC39-Meeting-January-2017.md

@@ -0,0 +1,132 @@
+---
+title: TC39 Meeeting January 2017
+author: Maggie Pint
+ahandle: maggiepint
+categories: [standards,javascript]
+date: February 6, 2017
+excerpt_separator: <!--more-->
+---
+
+Hello from your temporary JS Foundation Rep to TC39 - Maggie Pint!
+
+This month, we met at the PayPal campus in San Jose California. It was my first TC39 meeting, and the experience was extremely enlightening.
+<!--more-->
+
+I am happy to report that I got a friendly and positive reception from everyone there. The group as a whole was excited to have not one, but in fact
+three women attending a meeting. I was joined by Franziska Hinkelmann from the Node.js and V8 teams, and Anna,
+a student from the queer community who works with the Node.js team. This is the first meeting that had any women in it,
+so it was great that there could in fact be three of us.
+
+## On the Subject of Diversity
+
+The adoption of the new Code of Conduct for TC39 proceeds forward. This code of conduct is based off of the JS Foundation Code of Conduct
+and has been proven to work before. It is being put in place in hopes of making TC39 a more welcoming community for all.
+Of major concern was how code of conduct violations would be enforced. There was general consensus that any body investigating a code of conduct violation
+would need to be made up of a fairly diverse set of persons, some who were present when the violation occurred and some who were not. It was also decided that
+given the rarity of code of conduct violations, investigation bodies could be formed at the time of complaint, and there would not have to be one on call at all times.
+
+TC39 members are positive about moving forward with the code of conduct, and are encouraged to review and make comments before the March meeting.
+[Community feedback on the new code of conduct is welcome](https://github.com/tc39/code-of-conduct-proposal).
+
+## Getting Back to The Code
+
+[You can find a full agenda of what was discussed at this meeting here.](https://github.com/tc39/agendas/blob/master/2017/01.md) I won't discuss every single line item
+but I want to highlight a few proposals that are potentially of great benefit. In particular, I want to touch upon:
++ Null Propagation Operator
++ RegExp Lookbehind
++ 64 Bit Integers
++ IEEE 754 Sign Bit
+
+
+### Null Propagation Operator
+
+For the average developer, the `?.` operator - called here null propagation, but in other languages called null conditional, safe navigation, or elvis,
+is probably the most exciting proposal that moved forward at this meeting.
+It's use can be expressed easily by this code from [the proposal](https://docs.google.com/presentation/d/11O_wIBBbZgE1bMVRJI8kGnmC6dWCBOwutbN9SWOK0fU/view#slide=id.g1c161255c9_0_55);
+
+Without the null propagation operator:
+
+```js
+const firstName = (message
+  && message.body
+  && message.body.user
+  && message.body.user.firstName) || 'default';
+```
+
+With the null propagation operator:
+```js
+const firstName = message.body?.user?.firstName || 'default';
+```
+
+As you can see, the null propagation operator avoids constant checks for falsiness before navigating down an object graph, saving the developer substantial effort.
+As of right now, expect the null propagation operator to return `null` if it reaches a `null` property, and `undefined` if it reaches an `undefined` property.
+
+This proposal advanced to stage 1 with overwhelming support from the committee given it's usefulness. That said, there is substantial concern about the behavior of this
+operator in several edge cases. This is a common complexity when adding syntax to a language.
+
+### RegExp Lookbehind
+
+Regular expression lookbehinds are a common feature in the regex implementations of several programming languages including .NET, Python, PHP, Go, and Ruby.
+[This proposal](https://github.com/tc39/proposal-regexp-lookbehind) creates a regular expression syntax that allows developers to ensure that a specific pattern either
+precedes or DOES NOT precede a capture group, without actually capturing that pattern.
+
+One example scenario where this is useful is when capturing amounts of money. One can use a positive lookbehind to make sure that a dollar sign precedes an amount, by
+using the `(?<=...)` assertion. Completing the regular expression to look for digits, followed by a decimal, and then more digits we arrive at `/(?<=\$)\d+(\.\d*)?/`.
+This expression will match `$12.25` and return `12.15`.
+
+If one wanted to ensure that `$` did not precede the number, one could use a negative lookbehind. This syntax is denoted as `(?<!...)`. Assuming that one wanted to find
+all decimal values that were not US dollars, one could change the previous regular expression to `/(?<!\$)\d+(\.\d*)?/`. This would match `10.53` but not `$10.53`.
+
+This proposal was discussed at this meeting, but remained in stage 2. I just thought it was sweet, so I included it here.
+
+### 64 Bit Integers / BigInts
+
+I will not go deeply into [this proposal](https://gist.github.com/BrendanEich/4294d5c212a6d2254703), but I want to note that for OS interoperability purposes,
+the Node.js team has a strong need for 64 bit integers. In addition to these use cases, there are significant usages for 64 bit integers in cryptography and gaming.
+
+There is a feeling on the committee that it may be better to implement a bigint type - that is to say a type that is not limited to 64 bits, and can be optimized
+to the appropriate size based on the code, variables, and underlying system as appropriate. However, there is question as to whether this presents more work.
+Brendan Eich is investigating the implications of BigInt over Int64. If anybody has specific arguments about why a bigint type would be strongly preferable to an int64 type, we would be interested to hear your argument.
+
+This proposal did not advance, due to need for feedback.
+
+### IEEE 754 Sign Bit
+
+If you have ever dealt with ECMAScripts famous `-0` then you are familiar with the inconvenience not having a way to explicitly ask for the sign of an IEEE 754
+floating point number is. For those who aren't familiar with this issue, observe the following:
+
+```js
+Math.sign(2) // 1
+Math.sign(-2) // -1
+Math.sign(0) // 0
+Math.sign(-0) // -0
+```
+
+This is not terribly helpful when one wants to determine the actual sign of a number while handling all edge cases. [This proposal](http://jfbastien.github.io/papers/Math.signbit.html) introduces a new
+api, `Math.signbit()` that resolves this issue. Observe:
+
+```js
+Math.signbit(2) //false
+Math.signbit(-2) //true
+Math.signbit(0) //false
+Math.signbit(-0) //true
+```
+
+As you can see, asking if -0 is negative will in fact result in -0 being negative. WIN!
+
+This proposal advanced to stage 1 at this meeting.
+
+### Summary
+
+There were many other proposals discussed at the meeting, and I encourage you to look at everything that is in process on the [TC39 GitHub repository](https://github.com/tc39/proposals).
+
+## Community!
+
+Right now, TC39 is in the process of regrouping on the ECMAScript vision for the future. As part of this, several committee members will be reaching out to local
+user groups to hold discussions with users about what they want from the future of their programming language. I would love to hear more from any interested parties
+about things you hope to see. Feel free to reach out to me on twitter (@maggiepint) with any questions, or to [raise an issue on the JS Foundation standards repository](https://github.com/JSFoundation/standards).
+
+In addition, if you want to contribute your opinions, remember that TC39 discusses proposals on [GitHub](https://github.com/tc39) where you are welcome to have a voice.
+
+Finally, you can contribute code! TC39 maintains a test suite called [test262](https://github.com/tc39/test262) that provides feature acceptance testing to implementations of the spec. They would love more help to get further test
+coverage. Many of the implementors of ECMAScript use this test suite regularly, so contributions ensure better experiences for millions.