If ES ever introduces a way of customizing key equality in Maps, then the
literal syntax would have to be updated to include that "comparator"
function.

Also, curly braces with colons that separate the keys and values currently
denote objects, whose keys are limited in type.

Maps can have objects, booleans etc. as keys, so having `#{ true: "Yes",
false: "No" }` would be either ambiguous or confusing.

So I'm not totally comfortable with curly braces or colon in the syntax at
all. Suppose you have a key-value pair: KEY `{resourceType:"File",
resourceCategory: "Audio"}` with VALUE `()=>"Audio file"` I would rather
see something like

```
#
    {resourceType:"File", resourceCategory: "Audio"} -> ()=>"Audio file"
#
```

than trying to shoehorn the map syntax to share the existing object literal
syntax.

Personally I don't see the value in using maps at all yet until custom key
equality can be trivially provided to a map.

On Sun, 30 Jul 2017 at 23:53 Alexander Jones <alex at weej.com> wrote:

> https://github.com/tc39/proposal-pattern-matching/issues/47
>
> On 30 July 2017 at 17:13, Isiah Meadows <isiahmeadows at gmail.com> wrote:
>
>> Which is why I said there should be an issue filed there for it, so it
>> *does* get considered. My point was that we shouldn't get too in depth
>> independently of that proposal.
>>
>> Currently, that strawman is so incomplete in its current state it doesn't
>> even fully cover existing destructuring yet (like nested patterns). That's
>> where I was coming from when I recommended delaying until the pattern
>> matching proposal gets to a state we can consider it.
>>
>> On Sun, Jul 30, 2017, 12:04 Alexander Jones <alex at weej.com> wrote:
>>
>>> Hey Isiah
>>>
>>> Good shout - definitely worth connecting pattern matching/destructuring
>>> to the same concept.
>>>
>>> Let's assume `#{}` is kept, for the avoidance of bikeshedding:
>>>
>>> ```js
>>> const map = Map#{42: "the answer"};
>>>
>>> const #{42: fortyTwo} = someMap;
>>> // or?
>>> const {[42]: fortyTwo} = someMap;
>>> console.log(fortyTwo);  // "the answer"
>>> ```
>>>
>>> And presumably:
>>>
>>> ```js
>>> match (map) {
>>>     #{42: _}: `42 is ${_}`,
>>>     else: `who knows?`,
>>> }
>>> ```
>>>
>>> I'd be wary of just powering ahead with pattern matching /without/
>>> considering generalised mapping/sequence syntax...
>>>
>>> On 30 July 2017 at 16:41, Isiah Meadows <isiahmeadows at gmail.com> wrote:
>>>
>>>> How about for now, let's hold off on anything concrete until after the
>>>> pattern matching proposal gets to a point we can model the syntax and
>>>> semantics after that. There's quite a bit of overlap in terms of behavior,
>>>> too, which is more reason to consider this together with it.
>>>>
>>>> https://github.com/tc39/proposal-pattern-matching
>>>>
>>>> (I don't believe there's an issue over there for potential future
>>>> expansion to extensible destructuring assignment, but there should be.)
>>>>
>>>> On Sun, Jul 30, 2017, 11:34 Darien Valentine <valentinium at gmail.com>
>>>> wrote:
>>>>
>>>>> While static analysis is one advantage, there are additional reasons
>>>>> for this to be a syntactic proposal. A helper method like `Map.fromObject`
>>>>> could indeed be a useful addition to the language (though it is simple
>>>>> enough to do already: `new Map(Object.entries(obj))`) — however that does
>>>>> not work for maps whose keys are not also valid property keys.
>>>>>
>>>>> In general I’m in the less-new-syntax camp, but I find this idea
>>>>> intriguing. My initial impression is that it’s fairly convincing, mainly
>>>>> because my (purely anecdotal) experience is that it is an attempt to solve
>>>>> a real problem — many devs seem to be reluctant to use `Map` and `Set`,
>>>>> despite knowing they exist and are sometimes more appropriate models, and I
>>>>> think it is in part due to their "second class" nature; in ES folks are
>>>>> accustomed to "seeing" data structures. Similarly there is reluctance to
>>>>> work with subclasses of data structures, which are put on equal-footing by
>>>>> this proposal.
>>>>>
>>>>> The `#` is indeed ugly, but the particular symbol I imagine is highly
>>>>> bikesheddable and consideration of it could probably be deferred till it’s
>>>>> determined whether the core ideas of the proposal represent a worthwhile
>>>>> addition.
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
> _______________________________________________
> 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/20170731/f414ec2d/attachment.html>

If ES ever introduces a way of customizing key equality in Maps, then the
literal syntax would have to be updated to include that "comparator"
function.

Also, curly braces with colons that separate the keys and values currently
denote objects, whose keys are limited in type.

Maps can have objects, booleans etc. as keys, so having `#{ true: "Yes",
false: "No" }` would be either ambiguous or confusing.

So I'm not totally comfortable with curly braces or colon in the syntax at
all. Suppose you have a key-value pair: KEY `{resourceType:"File",
resourceCategory: "Audio"}` with VALUE `()=>"Audio file"` I would rather see something like

```javascript
const map =
    #
        {resourceType:"File", resourceCategory: "Audio"} -> ()=>"Audio file"
    #
```

than trying to shoehorn the map syntax to share the existing object literal
syntax.

Personally I don't see the value in using maps at all yet until custom key
equality can be trivially provided to a map.

If ES ever introduces a way of customizing key equality in Maps, then the
literal syntax would have to be updated to include that "comparator"
function.

Also, curly braces with colons that separate the keys and values currently
denote objects, whose keys are limited in type.

Maps can have objects, booleans etc. as keys, so having `#{ true: "Yes",
false: "No" }` would be either ambiguous or confusing.

So I'm not totally comfortable with curly braces or colon in the syntax at
all. Suppose you have a key-value pair: KEY `{resourceType:"File",
resourceCategory: "Audio"}` with VALUE `()=>"Audio file"` I would rather see something like

```
const map =
    #
        {resourceType:"File", resourceCategory: "Audio"} -> ()=>"Audio file"
    #
```

than trying to shoehorn the map syntax to share the existing object literal
syntax.

Personally I don't see the value in using maps at all yet until custom key
equality can be trivially provided to a map.

If ES ever introduces a way of customizing key equality in Maps, then the
literal syntax would have to be updated to include that "comparator"
function.

Also, curly braces with colons that separate the keys and values currently
denote objects, whose keys are limited in type.

Maps can have objects, booleans etc. as keys, so having `#{ true: "Yes",
false: "No" }` would be either ambiguous or confusing.

So I'm not totally comfortable with curly braces or colon in the syntax at
all. Suppose you have a key-value pair: KEY `{resourceType:"File",
resourceCategory: "Audio"}` with VALUE `()=>"Audio file"` I would rather see something like

```
#
    {resourceType:"File", resourceCategory: "Audio"} -> ()=>"Audio file"
#
```

than trying to shoehorn the map syntax to share the existing object literal
syntax.

Personally I don't see the value in using maps at all yet until custom key
equality can be trivially provided to a map.