6 ms·

Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things. [1] https://github.com/tc39/proposal-pattern-matching

Now if we could just get pattern matching[1] and optional chaining[2], that would really elevate things. [1] https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching [2] https://github.com/tc39/proposal-optional-chaining https://github.com/tc39/proposal-optional-chaining

cypressious 7y ago
Optional chaining recently reached stage 3, the babel plugin is available and TS is going to adopt it for 3.7.0.
- chriswwweb 7y ago
  Oh I didnt know about TS being so close to have it, that's great news EDIT: here is the confirmation TS 3.7.0 got tagged: https://github.com/microsoft/TypeScript/issues/16#issuecomment-515160784 https://github.com/microsoft/TypeScript/issues/16#issuecomme... EDIT 2: wow just noticed, that the issue ID is "16" and it has been open since Jul 15, 2014 (I guess: good things take time ... ;) )
- johnkpaul 7y ago
  This is awesome and hopefully 2020 bound. The only thing I remember from my few months of looking into Groovy was the "elvis operator" and being very jealous of it.
- deleted 7y ago
  [deleted]
chriswwweb 7y ago
Yeah very excited about optional chaning, which few days ago got accepted to stage 3 "candidate", so just one more stage (stage 4 "finished"), I guess and hope it will be ready for ES 2020
phpnode 7y ago
Pattern matching is a really important feature but I strongly dislike that proposal because it feels like it introduces a bunch of single purpose syntax that's going to restrict the ability to evolve the language in future. It feels like it's an addon, not a holistic solution. I would much, much rather that type annotation syntax gets standardised first, because it is comparatively easy to build pattern matching when that's in place but going the opposite direction is difficult. What is a type if not a pattern?
- pas 7y ago
  It seems that only `when` and `->`is the new syntax, no? The arrow seems something that could be replaced with `=>`, but anyway, neither seems to be very restrictive with regards to future syntax. (After all they are only defined in a `case` context, so the can be reused for whatever future purpose outside.) Plus it's a stage1 proposal, meaning it's far from serious. Could you link the type annotation proposal, I can't find it.
  - snek 7y ago
    There is no type annotation proposal.
    - sdegutis 7y ago
      TypeScript is becoming the de facto type annotations proposal.
      - Roboprog 7y ago
        Let me know when (type inference of) partial function application and object literals are easy in Typescript and I’ll consider it.
        sdegutis 7y ago
        Do you have a specific example of code that's hard to annotate in TypeScript? I've been using it for about a year without major issues (except somewhat slow compile times).
Kiro 7y ago
What's the point of pattern matching? Why not just a switch statement?
- halfmatthalfcat 7y ago
  Switch pivots off of one value, pattern matching allows you to match on types, destructured values, conditional execution based on the existence (or lack thereof) of those values or types. It's much more flexible then switch (but arguably more complex). See Scala[1] or Swifts[2]'s implementations. [1] https://docs.scala-lang.org/tour/pattern-matching.html https://docs.scala-lang.org/tour/pattern-matching.html [2] https://docs.swift.org/swift-book/ReferenceManual/Patterns.html https://docs.swift.org/swift-book/ReferenceManual/Patterns.h...
snek 7y ago
Optional chaining is stage 3, and major engines are actively implementing it.
sproketboy 7y ago
or a proper type system.
Gene_Parmesan 7y ago
I adore pattern matching when done well, but I'm sorry -- that syntax seems terrible and confusing. The use of `{ }` seems arbitrary. In JS braces are already used for both scope-delimiting and object literal notation; now they're going to have a third job? There has to be a better way. I understand it's based on destructuring; the syntax still just doesn't work for me.
- wjmao88 7y ago
  it is trying match one object to another, like how lodash find allows using an object.
- hajile 7y ago
  Ocaml, StandardML, F#, Erlang, and Rust all use that syntax for pattern matching. What other syntax would you propose to test values in a JS object?
  - deleted 7y ago
    [deleted]
tlrobinson 7y ago
These two and decorators (including function/assignment decorators) are the top 3 on my wishlist.
k__ 7y ago
Z is an interesting approach. https://dev.to/kayis/pattern-match-your-javascript-with-z-nff https://dev.to/kayis/pattern-match-your-javascript-with-z-nf...
codenirvana 7y ago
Waiting for Optional Chaining. It's in Stage 3 already.
- ehsankia 7y ago
  And this is why I love kotlin so much. It has all of these and so much more. Really excited to have .flat() and .flatMap() in ES2019, it's one of my favorite array feature in kotlin. Now just need something similar in python to avoid having to use itertools.chain or weird double comprehension.

cypressious 7y ago

Optional chaining recently reached stage 3, the babel plugin is available and TS is going to adopt it for 3.7.0.

chriswwweb 7y ago
Oh I didnt know about TS being so close to have it, that's great news EDIT: here is the confirmation TS 3.7.0 got tagged: https://github.com/microsoft/TypeScript/issues/16#issuecomment-515160784 https://github.com/microsoft/TypeScript/issues/16#issuecomme... EDIT 2: wow just noticed, that the issue ID is "16" and it has been open since Jul 15, 2014 (I guess: good things take time ... ;) )
johnkpaul 7y ago
This is awesome and hopefully 2020 bound. The only thing I remember from my few months of looking into Groovy was the "elvis operator" and being very jealous of it.
deleted 7y ago
[deleted]

chriswwweb 7y ago

Yeah very excited about optional chaning, which few days ago got accepted to stage 3 "candidate", so just one more stage (stage 4 "finished"), I guess and hope it will be ready for ES 2020

phpnode 7y ago

Pattern matching is a really important feature but I strongly dislike that proposal because it feels like it introduces a bunch of single purpose syntax that's going to restrict the ability to evolve the language in future. It feels like it's an addon, not a holistic solution. I would much, much rather that type annotation syntax gets standardised first, because it is comparatively easy to build pattern matching when that's in place but going the opposite direction is difficult. What is a type if not a pattern?

pas 7y ago
It seems that only `when` and `->`is the new syntax, no? The arrow seems something that could be replaced with `=>`, but anyway, neither seems to be very restrictive with regards to future syntax. (After all they are only defined in a `case` context, so the can be reused for whatever future purpose outside.) Plus it's a stage1 proposal, meaning it's far from serious. Could you link the type annotation proposal, I can't find it.
- snek 7y ago
  There is no type annotation proposal.
  - sdegutis 7y ago
    TypeScript is becoming the de facto type annotations proposal.
    - Roboprog 7y ago
      Let me know when (type inference of) partial function application and object literals are easy in Typescript and I’ll consider it.
      - sdegutis 7y ago
        Do you have a specific example of code that's hard to annotate in TypeScript? I've been using it for about a year without major issues (except somewhat slow compile times).

Kiro 7y ago

What's the point of pattern matching? Why not just a switch statement?

halfmatthalfcat 7y ago
Switch pivots off of one value, pattern matching allows you to match on types, destructured values, conditional execution based on the existence (or lack thereof) of those values or types. It's much more flexible then switch (but arguably more complex). See Scala[1] or Swifts[2]'s implementations. [1] https://docs.scala-lang.org/tour/pattern-matching.html https://docs.scala-lang.org/tour/pattern-matching.html [2] https://docs.swift.org/swift-book/ReferenceManual/Patterns.html https://docs.swift.org/swift-book/ReferenceManual/Patterns.h...

snek 7y ago

Optional chaining is stage 3, and major engines are actively implementing it.

sproketboy 7y ago

or a proper type system.

Gene_Parmesan 7y ago

I adore pattern matching when done well, but I'm sorry -- that syntax seems terrible and confusing. The use of `{ }` seems arbitrary. In JS braces are already used for both scope-delimiting and object literal notation; now they're going to have a third job? There has to be a better way. I understand it's based on destructuring; the syntax still just doesn't work for me.

wjmao88 7y ago
it is trying match one object to another, like how lodash find allows using an object.
hajile 7y ago
Ocaml, StandardML, F#, Erlang, and Rust all use that syntax for pattern matching. What other syntax would you propose to test values in a JS object?
- deleted 7y ago
  [deleted]

tlrobinson 7y ago

These two and decorators (including function/assignment decorators) are the top 3 on my wishlist.

k__ 7y ago

Z is an interesting approach. https://dev.to/kayis/pattern-match-your-javascript-with-z-nff https://dev.to/kayis/pattern-match-your-javascript-with-z-nf...

codenirvana 7y ago

Waiting for Optional Chaining. It's in Stage 3 already.

ehsankia 7y ago
And this is why I love kotlin so much. It has all of these and so much more. Really excited to have .flat() and .flatMap() in ES2019, it's one of my favorite array feature in kotlin. Now just need something similar in python to avoid having to use itertools.chain or weird double comprehension.