4 ms·

TypeScript: Vote for Experimental Support of Optional Chaining

15 points by IvanGoncharov 8y ago

fixermark 8y ago
Clarification: TS team is aware of this feature desire and has a plan to support it (their plan is hinged on an existing standard that is still being locked down for JS; details in https://github.com/Microsoft/TypeScript/issues/16 https://github.com/Microsoft/TypeScript/issues/16). No real benefit in voting on it now, other than to express your added desire for a thing the TS team already knows people want.
Waterluvian 8y ago
Interesting. I think I saw this in Swift? Or c#? I guess in Python this is where EAFP comes in. I definitely hate chains of guards to get at a nested property.
- kreetx 8y ago
  In haskell the lens library does this -- it's a useful feature to have.
- mattferderer 8y ago
  C# has it.
  - nathanaldensr 8y ago
    Yep, they're called null conditional operators[1]. [1]: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
- LocalPCGuy 8y ago
  Quite a few language have this feature, and it is a Stage 1 proposal to become a part of the JS spec
- tijs 8y ago
  https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type
evmar 8y ago
Language design should not be determined by "votes".
- fixermark 8y ago
  Wellllllll.... Languages are used by people. So it depends, a lot, on the goals of the stewards of a language. Votes can be a useful signal for whether or not people are going to care about your language enough to adopt it. ... but it's absolutely true that voters can vote for the moon and then skip off blissfully, never having to worry about how you implement the Apollo project.
  - plorkyeran 8y ago
    Yeah, votes aren't useless. Obviously you shouldn't just go implement the things that get the most votes without question and ignore everything else. However, if there's two things I think I should implement and the community is much more excited about one than the other, I should probably do that one first. If something gets a whole bunch of votes and I think it's a bad idea that means I need to actually take the time to explain why it's bad rather than just leaving it languishing in the backlog. If I think something's going to be great but it doesn't have a lot of votes, it means that I need to put more work into explaining why it's useful than I might otherwise.
- nojvek 8y ago
  Language design priorities should definitely decided based on votes.
- swsieber 8y ago
  Correct. It is valuable feedback though.
tlackemann 8y ago
It's been years since this proposal and everyone keeps arguing over semantics yet I don't see any semantics being changed. So what's the holdup? I understand constraints and external factors/dependencies but this seems like such a trivial change that it boggles me we don't have this as a standard feature yet.

15 points by IvanGoncharov 8y ago

Clarification: TS team is aware of this feature desire and has a plan to support it (their plan is hinged on an existing standard that is still being locked down for JS; details in https://github.com/Microsoft/TypeScript/issues/16 https://github.com/Microsoft/TypeScript/issues/16). No real benefit in voting on it now, other than to express your added desire for a thing the TS team already knows people want.

Waterluvian 8y ago

Interesting. I think I saw this in Swift? Or c#? I guess in Python this is where EAFP comes in. I definitely hate chains of guards to get at a nested property.

kreetx 8y ago
In haskell the lens library does this -- it's a useful feature to have.
mattferderer 8y ago
C# has it.
- nathanaldensr 8y ago
  Yep, they're called null conditional operators[1]. [1]: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
LocalPCGuy 8y ago
Quite a few language have this feature, and it is a Stage 1 proposal to become a part of the JS spec
tijs 8y ago
https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type

evmar 8y ago

Language design should not be determined by "votes".

fixermark 8y ago
Wellllllll.... Languages are used by people. So it depends, a lot, on the goals of the stewards of a language. Votes can be a useful signal for whether or not people are going to care about your language enough to adopt it. ... but it's absolutely true that voters can vote for the moon and then skip off blissfully, never having to worry about how you implement the Apollo project.
- plorkyeran 8y ago
  Yeah, votes aren't useless. Obviously you shouldn't just go implement the things that get the most votes without question and ignore everything else. However, if there's two things I think I should implement and the community is much more excited about one than the other, I should probably do that one first. If something gets a whole bunch of votes and I think it's a bad idea that means I need to actually take the time to explain why it's bad rather than just leaving it languishing in the backlog. If I think something's going to be great but it doesn't have a lot of votes, it means that I need to put more work into explaining why it's useful than I might otherwise.
nojvek 8y ago
Language design priorities should definitely decided based on votes.
swsieber 8y ago
Correct. It is valuable feedback though.

tlackemann 8y ago

It's been years since this proposal and everyone keeps arguing over semantics yet I don't see any semantics being changed. So what's the holdup? I understand constraints and external factors/dependencies but this seems like such a trivial change that it boggles me we don't have this as a standard feature yet.