<h1 dir="auto">Non-nullable types (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="134699594" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/7140" data-hovercard-type="pull_request" data-hovercard-url="/microsoft/TypeScript/pull/7140/hovercard" href="https://github.com/microsoft/TypeScript/pull/7140">#7140</a>)</h1>
<h2 dir="auto">Question marks on types</h2>
<p dir="auto">Let's start the bike-shedding! What does <code class="notranslate">T?</code> mean?</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="function foo(x?: string) {
    // x: string | undefined
}

function foo(x: string?) {
    // ?????
}

function foo(x?: string?) {
    // x: string | undefined | ?????
}"><pre class="notranslate"><span class="pl-k">function</span> <span class="pl-en">foo</span><span class="pl-kos">(</span><span class="pl-s1">x</span>?: <span class="pl-smi">string</span><span class="pl-kos">)</span> <span class="pl-kos">{</span>
    <span class="pl-c">// x: string | undefined</span>
<span class="pl-kos">}</span>

<span class="pl-k">function</span> <span class="pl-en">foo</span><span class="pl-kos">(</span><span class="pl-s1">x</span>: <span class="pl-smi">string</span>?<span class="pl-kos">)</span> <span class="pl-kos">{</span>
    <span class="pl-c">// ?????</span>
<span class="pl-kos">}</span>

<span class="pl-k">function</span> <span class="pl-en">foo</span><span class="pl-kos">(</span><span class="pl-s1">x</span>?: <span class="pl-smi">string</span>?<span class="pl-kos">)</span> <span class="pl-kos">{</span>
    <span class="pl-c">// x: string | undefined | ?????</span>
<span class="pl-kos">}</span></pre></div>
<ul dir="auto">
<li><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/ahejlsberg/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/ahejlsberg">@ahejlsberg</a>: It's hard to imagine a world where <code class="notranslate">T?</code> means <em>only</em> <code class="notranslate">T | null</code> or <em>only</em> <code class="notranslate">T | undefined</code>.</li>
<li>There is a school of thought that says "neither - this just doesn't need to exist".
<ul dir="auto">
<li>Just ship two type aliases for <code class="notranslate">T | null</code> and <code class="notranslate">T | undefined</code> in <code class="notranslate">lib.d.ts</code></li>
<li>We can sort of see that. It's not crazy.</li>
<li>We can't satisfy everyone - we're going to piss someone off.</li>
<li>But if we ship this without a <code class="notranslate">?</code> type modifier, it's the first thing we're going to hear, and we're going to hear it for the rest of our lives.</li>
</ul>
</li>
<li>What's crazy about <code class="notranslate">T | null</code>?
<ul dir="auto">
<li>You have an optional accessor that returns <code class="notranslate">number? | undefined</code>.
<ul dir="auto">
<li>You end up with these awkward, funny-looking types.</li>
</ul>
</li>
<li>Lack of symmetry between optional members and nullish types.
<ul dir="auto">
<li>Becomes like the <code class="notranslate">const</code> modifier in C++.</li>
<li>Nobody understands where the heck to put <code class="notranslate">const</code> (before <code class="notranslate">*</code>, after <code class="notranslate">*</code>, at the end of a signature), and the differences are hard for people to grasp.
<ul dir="auto">
<li>We understand it, but our users will get tripped up <em>a lot</em>.</li>
</ul>
</li>
</ul>
</li>
<li>People will definitely be confused about which to do.
<ul dir="auto">
<li>Users on GitHub did not seem to be concerned with it - they understood very well.
<ul dir="auto">
<li>Confirmation bias - these are people who are interested in language design to begin with.</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>Too many people are doing <code class="notranslate">null</code> to ignore that scenario.
<ul dir="auto">
<li>Ultimately the question becomes is this disjoint or does it combine with the "other" use of <code class="notranslate">?</code> on optional parameters/properties.</li>
</ul>
</li>
<li><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/RyanCavanaugh/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/RyanCavanaugh">@RyanCavanaugh</a>: Extremely against <code class="notranslate">T?</code> meaning <code class="notranslate">T | null | undefined</code> because it muddies waters - So if we can't come to a conclusion, I think we should hold off on it.</li>
<li>We want to lead people to a pit of success, and we can't repeat the problem we have with modules.</li>
<li>Only consistency in discussion on thread is that there is no consistency.</li>
<li>We don't feel confident that we can do the "right" thing here out of the gate.</li>
<li>If people go out and fix type definitions and inappropriately use <code class="notranslate">?</code>, then you've made the ecosystem worse - we need to wary of this possibility.</li>
<li><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/Aleksey-Bykov/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/Aleksey-Bykov">@Aleksey-Bykov</a> you get a ⭐</li>
<li>Consensus: come back to this, since this is not a blocker for non-nullable types anyway.
<ul dir="auto">
<li>Also, look into supplying type aliases in <code class="notranslate">lib.d.ts</code>.</li>
</ul>
</li>
</ul>
<h2 dir="auto">Optional members on new members</h2>
<ul dir="auto">
<li>Considering adding question marks on other members (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="139097459" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/7426" data-hovercard-type="issue" data-hovercard-url="/microsoft/TypeScript/issues/7426/hovercard?comment_id=195392211&amp;comment_type=issue_comment" href="https://github.com/microsoft/TypeScript/issues/7426#issuecomment-195392211">#7426 (comment)</a>)
<ul dir="auto">
<li>On local variable names (e.g. <code class="notranslate">let x?: number</code>).</li>
<li>On property declarations in classes (e.g. <code class="notranslate">class Foo { x?: number }</code>).</li>
<li>On call signatures (e.g. <code class="notranslate">function val(x?: string)?: number</code>).</li>
<li>On index signatures (e.g. <code class="notranslate">[x: string]?: Entity</code>).</li>
</ul>
</li>
<li>We said it wasn't necessary because classes always have <code class="notranslate">undefined</code> by default, but non-nullable types make the world quite different.</li>
<li>Variables are more of a <em>questionable</em> (pun intended) case - not entirely certain.
<ul dir="auto">
<li>It seems like this would actually give you a case to say that your variable can be <code class="notranslate">undefined</code> and reflects that in the type.</li>
<li>Can we use that to model the dual of this on <code class="notranslate">?</code> in types?
<ul dir="auto">
<li>Let's not go down that rabbit-hole.</li>
</ul>
</li>
</ul>
</li>
<li>Call signatures would have an awkward syntax.</li>
<li>Consensus: do it for properties, keep the rest this in mind, but come back to it.</li>
</ul>
<h2 dir="auto">Control-flow based type checking</h2>
<ul dir="auto">
<li>We're going to need to do it.</li>
<li>We think we can do it with no significant perf hit.</li>
<li>Get perfect definite assignment errors.</li>
<li>Type guards should work perfectly.</li>
<li>We'll keep people posted.</li>
</ul>
<h1 dir="auto">UMD module support (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="136830403" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/7264" data-hovercard-type="pull_request" data-hovercard-url="/microsoft/TypeScript/pull/7264/hovercard" href="https://github.com/microsoft/TypeScript/pull/7264">#7264</a>)</h1>
<ul dir="auto">
<li>Idea with UMD modules is you write a declaration file.</li>
<li>In that same file, you write <code class="notranslate">export as namespace Foo</code> where <code class="notranslate">Foo</code> is some arbitrary identifier.</li>
<li>In a module, only if you use a <code class="notranslate">/// &lt;reference path="..." /&gt;</code>, is <code class="notranslate">Foo</code> visible.</li>
<li>In a script context, <code class="notranslate">Foo</code> is always visible if the <code class="notranslate">.d.ts</code> is in the compilation context.
<ul dir="auto">
<li>Idea is that you're in a script/"non-module" context.</li>
</ul>
</li>
<li>This is the new, better, way to write type definitions that need to be shared between old script-style code and modules.
<ul dir="auto">
<li>The problem is that you always needed to duplicate your definitions across two different definition files, one which used an <code class="notranslate">export =</code>.</li>
</ul>
</li>
<li>Problem: how do you reflect the type of the module itself?
<ul dir="auto">
<li>
<p dir="auto">Sometimes modules have members that refer to themselves.</p>
</li>
<li>
<p dir="auto">We're still flexible here!</p>
</li>
<li>
<p dir="auto">Continue using some value, use <code class="notranslate">export =</code>, and then use an <code class="notranslate">export namespace as Foo</code>.</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="interface jQueryStatic {
    foo: jQueryStatic
}

let jQuery: jQueryStatic;
export = jQuery;
export as namespace jQuery;"><pre class="notranslate"><span class="pl-k">interface</span> <span class="pl-smi">jQueryStatic</span> <span class="pl-kos">{</span>
    <span class="pl-c1">foo</span>: <span class="pl-smi">jQueryStatic</span>
<span class="pl-kos">}</span>

<span class="pl-k">let</span> <span class="pl-s1">jQuery</span>: <span class="pl-smi">jQueryStatic</span><span class="pl-kos">;</span>
<span class="pl-k">export</span> <span class="pl-c1">=</span> <span class="pl-s1">jQuery</span><span class="pl-kos">;</span>
<span class="pl-k">export</span> <span class="pl-k">as</span> <span class="pl-k">namespace</span> <span class="pl-s1">jQuery</span><span class="pl-kos">;</span></pre></div>
</li>
</ul>
</li>
<li>
<h2 dir="auto">Why does <code class="notranslate">/// &lt;reference path="..." /&gt;</code> affect things? Why not just use a global module augmentation?</h2>
</li>
</ul>
<h1 dir="auto">Library include directives (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="136830217" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/7263" data-hovercard-type="pull_request" data-hovercard-url="/microsoft/TypeScript/pull/7263/hovercard" href="https://github.com/microsoft/TypeScript/pull/7263">#7263</a>)</h1>
<ul dir="auto">
<li>Answer to the question of "How do we easily resolve types for script/global code?"
<ul dir="auto">
<li>Need to avoid situations where users have duplicate definitions due to "global code" being treated as conflicting even though they might refer to the same entities.</li>
</ul>
</li>
<li>Syntax: <code class="notranslate">/// &lt;reference library="jquery" /&gt;</code></li>
<li>What is the order of resolution for declaration files?
<ul dir="auto">
<li>Take <code class="notranslate">/// &lt;reference library="jquery" /&gt;</code>.</li>
<li>Start from current module location.</li>
<li>Look for files walking up the spine of directories. For each directory:
<ol dir="auto">
<li>If you see a file named <code class="notranslate">jquery.d.ts</code>, use that.</li>
<li>If you see a directory named <code class="notranslate">typings</code>, look in there.</li>
<li>If you see a directory named <code class="notranslate">node_modules</code>
<ol dir="auto">
<li>Try to resolve in <code class="notranslate">node_modules/jquery/package.json</code> or use the <code class="notranslate">node_modules/jquery/index.d.ts</code>.</li>
<li>Try to resolve in <code class="notranslate">node_modules/jquery/package.json</code> or use the <code class="notranslate">node_modules/@types/jquery/index.d.ts</code> (or something similar).</li>
</ol>
</li>
</ol>
</li>
</ul>
</li>
<li>Meeting cut short - may be more to the algorithm.</li>
</ul>
<p dir="auto">The following TypeScript with async/await...</p>
<div class="highlight highlight-source-ts notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="public async get(from: number, to: number): Promise&lt;Array&lt;M&gt;&gt; {
  let models: Array&lt;M&gt; = await this.persistant_repo.get(from, to);"><pre class="notranslate"><span class="pl-k">public</span> <span class="pl-s1">async</span> <span class="pl-en">get</span><span class="pl-kos">(</span><span class="pl-s1">from</span>: <span class="pl-s1">number</span><span class="pl-kos">,</span> <span class="pl-s1">to</span>: <span class="pl-s1">number</span><span class="pl-kos">)</span>: <span class="pl-smi">Promise</span><span class="pl-c1">&lt;</span><span class="pl-smi">Array</span><span class="pl-c1">&lt;</span><span class="pl-smi">M</span><span class="pl-c1">&gt;&gt;</span> <span class="pl-kos">{</span>
  <span class="pl-s1">let</span> <span class="pl-c1">models</span>: <span class="pl-smi">Array</span><span class="pl-kos">&lt;</span><span class="pl-smi">M</span><span class="pl-kos">&gt;</span> <span class="pl-c1">=</span> <span class="pl-k">await</span> <span class="pl-smi">this</span><span class="pl-kos">.</span><span class="pl-c1">persistant_repo</span><span class="pl-kos">.</span><span class="pl-en">get</span><span class="pl-kos">(</span><span class="pl-s1">from</span><span class="pl-kos">,</span> <span class="pl-s1">to</span><span class="pl-kos">)</span><span class="pl-kos"></span><span class="pl-kos">;</span></pre></div>
<p dir="auto">produces the following JavaScript with a yield outside of a generator...</p>
<div class="highlight highlight-source-js notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="ModelsRepoDecorator.prototype.get = function (from, to) {
  var _this = this;
  var models = yield this.persistant_repo.get(from, to);"><pre class="notranslate"><span class="pl-v">ModelsRepoDecorator</span><span class="pl-kos">.</span><span class="pl-c1">prototype</span><span class="pl-kos">.</span><span class="pl-en">get</span> <span class="pl-c1">=</span> <span class="pl-k">function</span> <span class="pl-kos">(</span><span class="pl-s1">from</span><span class="pl-kos">,</span> <span class="pl-s1">to</span><span class="pl-kos">)</span> <span class="pl-kos">{</span>
  <span class="pl-k">var</span> <span class="pl-s1">_this</span> <span class="pl-c1">=</span> <span class="pl-smi">this</span><span class="pl-kos">;</span>
  <span class="pl-k">var</span> <span class="pl-s1">models</span> <span class="pl-c1">=</span> <span class="pl-k">yield</span> <span class="pl-smi">this</span><span class="pl-kos">.</span><span class="pl-c1">persistant_repo</span><span class="pl-kos">.</span><span class="pl-en">get</span><span class="pl-kos">(</span><span class="pl-s1">from</span><span class="pl-kos">,</span> <span class="pl-s1">to</span><span class="pl-kos">)</span><span class="pl-kos">;</span><span class="pl-kos"></span></pre></div>
<p dir="auto">I'm not certain, but I don't think <code class="notranslate">yield</code> should work outside of a generator. I'm running <code class="notranslate">tsc src/**/*.ts --outDir dist --sourceMap</code> and my tsconfig looks like this...</p>
<div class="highlight highlight-source-json notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="{
  &quot;compilerOptions&quot;: {
    &quot;module&quot;: &quot;commonjs&quot;,
    &quot;target&quot;: &quot;ES6&quot;,
    &quot;noImplicitAny&quot;: true,
    &quot;removeComments&quot;: true,
    &quot;preserveConstEnums&quot;: true,
    &quot;sourceMap&quot;: true,
    &quot;jsx&quot;: &quot;react&quot;
  }
}"><pre class="notranslate">{
  <span class="pl-ent">"compilerOptions"</span>: {
    <span class="pl-ent">"module"</span>: <span class="pl-s"><span class="pl-pds">"</span>commonjs<span class="pl-pds">"</span></span>,
    <span class="pl-ent">"target"</span>: <span class="pl-s"><span class="pl-pds">"</span>ES6<span class="pl-pds">"</span></span>,
    <span class="pl-ent">"noImplicitAny"</span>: <span class="pl-c1">true</span>,
    <span class="pl-ent">"removeComments"</span>: <span class="pl-c1">true</span>,
    <span class="pl-ent">"preserveConstEnums"</span>: <span class="pl-c1">true</span>,
    <span class="pl-ent">"sourceMap"</span>: <span class="pl-c1">true</span>,
    <span class="pl-ent">"jsx"</span>: <span class="pl-s"><span class="pl-pds">"</span>react<span class="pl-pds">"</span></span>
  }
}</pre></div>
<p dir="auto">I think this may be a duplicate of <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="98861332" data-permission-text="Title is private" data-url="https://github.com/microsoft/TypeScript/issues/4135" data-hovercard-type="issue" data-hovercard-url="/microsoft/TypeScript/issues/4135/hovercard" href="https://github.com/microsoft/TypeScript/issues/4135">#4135</a>, but I'm not sure how the solution there can be applied here.</p>