<p dir="ltr">Why not make it desugar to a direct function call with a single array of pairs? It's so parsed as a regular object, so shorthands can still be used. </p>
<p dir="ltr">`Map#{foo: 1, bar: 2, 3: "baz"}`<br>
`Map[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`</p>
<p dir="ltr">`Object#{foo: 1, bar: 2, 3: "baz"}`<br>
`Object[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`</p>
<p dir="ltr">`Object.null#{foo: 1, bar: 2, 3: "baz"}`<br>
`Object.null[Symbol.fromHash]([[foo", 1], ["bar", 2], ["3", "baz]])`</p>
<p dir="ltr">(`bar` doesn't have [[Construct]])<br>
`Object#{foo, bar() {}}`<br>
`Object[Symbol.fromHash]([[foo", foo], ["bar", function () {}]])`</p>
<p dir="ltr">And as for implementation, use this:</p>
<p dir="ltr">```js<br>
extend class Map {<br>
  static [Symbol.fromHash](pairs) {<br>
    return new this(pairs);<br>
  }<br>
}</p>
<p dir="ltr">// etc... </p>
<p dir="ltr">function SetKeys(target, pairs) {<br>
  for (const [key, value] of pairs) {<br>
      target[key] = value<br>
    }<br>
    return target<br>
}</p>
<p dir="ltr">extend class Object {<br>
  static [Symbol.fromHash](pairs) {<br>
    return SetKeys({}, pairs)<br>
  }</p>
<p dir="ltr">  static null(pairs) {<br>
    return SetKeys(Object.create(null), pairs)<br>
  }<br>
}<br>
```</p>
<p dir="ltr">Pretty simple IMHO. A helper decorator could even be made. </p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 28, 2015, 14:34 Alexander Jones <<a href="mailto:alex@weej.com">alex@weej.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also I would like to reiterate that errors in the shape of the N-by-2 array are only caught at runtime. That's really not ideal.<span></span><br><br>On Wednesday, 28 October 2015, Dave Porter <<a href="mailto:david_porter@apple.com" target="_blank">david_porter@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I don’t love any of the specific suggestions so far, but saving 3 + 2n keystrokes isn't the point – readability and learnability are. Visually, `new Map([[‘foo’, 42]])` is a mess.</div><br><div><blockquote type="cite"><div>On Oct 28, 2015, at 9:28 AM, Michał Wadas <<a>michalwadas@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div><div>Difference between any proposed here syntax and current state ( new Map([ [1,2], [2,3] ]); ) is..<br><br></div>3 characters + 2 characters/entry.<br><br></div><br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-28 17:22 GMT+01:00 Mohsen Azimi <span dir="ltr"><<a>me@azimi.me</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">When I look at `Map#{"foo": 42}` I don't see much difference with `new Map([['foo', 42]])`.<div><br></div><div>Since you can pass expressions there, it's already possible to do it with current syntax. There is only a bunch of extra brackets(`[` and `]`) that I don't like.</div><div><br></div></div><div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 28, 2015 at 5:51 AM Alexander Jones <<a>alex@weej.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ah, there is actually a good case for keeping barewords in object literals but removing them from map literals, and that's due to objects accessing string properties as bare words, too. This is almost never the case for other map types.<div><br></div><div>```</div><div>const o = {foo: 42};</div><div>o.foo === 42;</div><div>o.bar = 43;</div><div><br></div><div>const m = Map#{"foo": 42};</div><div>m.get("foo") === 42;</div><div>m.set("bar", 43);</div><div>```</div><div><br></div><div>Would you agree?</div><div><span></span><br><br>On Wednesday, 28 October 2015, Alexander Jones <<a>alex@weej.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Herby<div><br></div><div>Agree with your concerns about symmetry with object literals, but many of the uses of maps benefit from having non string keys, and in such case generally everything would involve wrapping in []. Trying to use an Array as a key would be quite ugly with the extra squares required</div><div><br></div><div>```</div><font size="2"><span style="background-color:rgba(255,255,255,0)">const precachedResults = MyMap#{[[1, 2, 3]]: [1, 4, 9]}</span></font><br><div>vs</div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">const precachedResults = MyMap#{[1, 2, 3]: [1, 4, 9]}</span></font></div><div><div>```</div><div><br></div><div>Perhaps a middle ground could be that if you want to use an expression that would otherwise be a bare word, you enclose in parens. The visual binding of the colon is deceptive anyway, so I tend to do this if the key expression contains a space:</div><div><br></div><div>```</div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">MyMap#{1 + 2 + 3: 6}</span></font><br></div><div>vs.</div><div><span style="font-size:small;background-color:rgba(255,255,255,0)">MyMap#{(1 + 2 + 3): 6}</span></div><div>```</div><div><br></div><div>But I think I still prefer that the parsing for the key part is just standard expression evaluation, personally, and the POJSO literal barewords remain the only special case.</div><div><br></div><div>Indeed,</div><div><br></div><div>```</div><div>Object#{1: "one", Symbol(): "sym"}</div><div>```</div><div><br></div><div>Could Object-key-ify the keys, i.e. turn them into strings if not symbols, and Just Work (but a default implementation on the Object prototype is questionable!). That said I'm not sure we should be using Object for this kind of thing. At this point I don't know what a raw `#{}` should produce... There may be a better use case for it in the future, horrible ASI complexities notwithstanding.</div><div><br></div><div>Alex</div><div><br></div><br><div>On Wednesday, 28 October 2015, Herby Vojčík <<a>herby@mailbox.sk</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Alexander Jones wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok, thanks for clarifying. Not only does it preserve order but it also<br>
permits non-string keys. You're still missing one detail which is that<br>
`bar` would actually be a variable not a string key.<br>
<br>
Another example to clarify that the key part would be an expression:<br>
<br>
```<br>
Map#{foo(42) + 7: "bar"}<br>
```<br>
<br>
I prefer this over the precedent set by object literals which would<br>
require that [] are used around a key expression ("computed key") simply<br>
</blockquote>
<br>
I, on the other hand, think it should match object literals completely. So your example would be<br>
<br>
```<br>
Map#{[foo(42)+7]: "bar"}<br>
```<br>
<br>
Yes, it's just for consistency and less WTF moment while learning the details.<br>
<br>
OTOH, there could be consistent contraproposal of:<br>
<br>
```<br>
Object#{foo(42) + 7: "bar"}<br>
null#{foo(42) + 7: "bar"}<br>
#{foo(42) + 7: "bar"}<br>
```<br>
<br>
where the first is equivalent to {[foo(42)+7]: "bar"}, the second is pure container (Object.create(null)) filled with properties, and the third is the default case, but I don't know which of the previous two - the first is probably less confusing, though the feels more clean.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
due to relieving the syntax noise, which is what this idea is all about.<br>
Also, this is how it works in Python and I make no apologies about the<br>
similarities ;)<br>
<br>
Alex<br>
<br>
On Wednesday, 28 October 2015, Viktor Kronvall<br>
<<a>viktor.kronvall@gmail.com</a> <mailto:<a>viktor.kronvall@gmail.com</a>>> wrote:<br>
<br>
    Hello Alexander,<br>
<br>
    I see now that I misread your desugaring.<br>
<br>
    I read:<br>
<br>
    ```<br>
    Map#{1: 6, bar: 'Hello', 2: 8};<br>
    ```<br>
    as being desugared to:<br>
<br>
    ```<br>
    Map[Symbol.literalOf]({1: 6, bar: 'Hello', 2: 8}[Symbol.iterator]());<br>
    ```<br>
<br>
    But your proposal clearly states that is should be:<br>
<br>
    ```<br>
    Map[Symbol.literalOf]([[1, 6], ['bar', 'Hello'],<br>
    [2,8]][Symbol.iterator]());<br>
    ```<br>
<br>
    Which would preserve lexical ordering of entries. The fault is<br>
    completely mine. Sorry.<br>
<br>
    I like this proposal as it is extensible and not that noisy in<br>
    syntax. Using the `#` for this doesn't<br>
    seem like a bad idea either. People coming from Erlang will be<br>
    familiar with this as well.<br>
<br>
<br>
    2015-10-28 10:53 GMT+01:00 Alexander Jones <<a>alex@weej.com</a><br>
    <javascript:_e(%7B%7D,'cvml','<a>alex@weej.com</a>');>>:<br>
<br>
        Hi Victor<br>
<br>
        Not sure I understand - the desugaring I wrote would absolutely<br>
        preserve the written ordering because it speaks in terms of an<br>
        ArrayIterator of key-value pairs. If the map type to which it's<br>
        applied chooses to forget the ordering then that's fine.<br>
<br>
        Alex<br>
<br>
<br>
        On Wednesday, 28 October 2015, Viktor Kronvall<br>
        <<a>viktor.kronvall@gmail.com</a><br>
        <javascript:_e(%7B%7D,'cvml','<a>viktor.kronvall@gmail.com</a>');>> wrote:<br>
<br>
             > ```<br>
            >  const map = IMap#{"foo": 42, bar: 44};<br>
            >  ```<br>
             > It could desugar as, for the sake of example:<br>
             ><br>
             > ```<br>
             > Foo#{key: value, ...}<br>
             > ➔<br>
             > Foo[Symbol.literalOf]([[key, value], ...][Symbol.iterator]())<br>
             > ```<br>
<br>
            I like this proposal. However, Maps should guarantee<br>
            insertion order when traversing the keys and values and<br>
            desugaring it like that does not respect this guarantee or<br>
            more precisely it will lead to (in my opinion) unexpected<br>
            order of the keys.<br>
<br>
            ```<br>
            Object.keys({1: 6, bar: 'Hello', 2: 8}); // → [ '1', '2',<br>
            'bar' ]<br>
            ```<br>
<br>
            If I'm not mistaken this will be same order for `{1: 6, bar:<br>
            'Hello', 2: 8}[Symbol.iterator]()`.<br>
<br>
            This implies that:<br>
<br>
            ```<br>
            Map#{1: 6, bar: 'Hello', 2: 8};<br>
            ```<br>
<br>
            Will not have entries in the order `[[1, 6], ['bar',<br>
            'Hello'], [2,8]]` but instead `[[1,6], [2,8], ['bar','Hello']]`.<br>
<br>
            This means that possible future destructuring of a Map will<br>
            be harder to reason about.<br>
<br>
<br>
            2015-10-28 2:21 GMT+01:00 Alexander Jones <<a>alex@weej.com</a>>:<br>
<br>
                True, but easy to mess up and only be treated to a<br>
                runtime error. Three nested brackets at the start and<br>
                end could definitely be better, and this just encourages<br>
                people to use POJSOs instead. Also not a very uniform<br>
                interface if you look at how to construct a Map, Set or<br>
                Immutable.List at present, though admittedly constructor<br>
                call for the ES6 types would be a partial improvement.<br>
<br>
                On Wednesday, 28 October 2015, Tab Atkins Jr.<br>
                <<a>jackalmage@gmail.com</a>> wrote:<br>
<br>
                    On Wed, Oct 28, 2015 at 8:36 AM, Alexander Jones<br>
                    <<a>alex@weej.com</a>> wrote:<br>
                     > I agree this is pretty important. Using actual<br>
                    maps really frees up a lot of<br>
                     > complexity, but the syntax is cumbersome to say<br>
                    the least.<br>
                     ><br>
                     > Whatever the decided syntax, bare words as string<br>
                    keys is a really bad idea<br>
                     > IMO. The key syntax should be parsed as an<br>
                    expression, like the values are,<br>
                     > and like they are in basically every other language.<br>
                     ><br>
                     > Another outstanding issue is that we might want<br>
                    the syntax for<br>
                     > `Immutable.Map`, or `WeakMap`, or `MapTwoPointOh`<br>
                    that improves deficiency<br>
                     > $x, $y and $z. I'd say introducing a special<br>
                    syntax for `Map` right now is<br>
                     > not ideal.<br>
<br>
                    Currently, the "extensible literal syntax" for this<br>
                    isn't that bad:<br>
<br>
                    const bar = 43;<br>
                    const map = Immutable.Map([["foo", 42], [bar, 44]]);<br>
<br>
                    It's a little more verbose because the entries have<br>
                    to be surrounded<br>
                    by [], but hey.<br>
<br>
                    ~TJ<br>
<br>
<br>
                _______________________________________________<br>
                es-discuss mailing list<br>
                <a>es-discuss@mozilla.org</a><br>
                <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br>
<br>
<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a>es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote>
</blockquote></div></div>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a>es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a>es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>es-discuss mailing list<br><a>es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br></div></blockquote></div><br></div></blockquote>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>