Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion Backlog Slog, 2/1/2020 #42591

Closed
DanielRosenwasser opened this issue Feb 1, 2021 · 6 comments
Closed

Suggestion Backlog Slog, 2/1/2020 #42591

DanielRosenwasser opened this issue Feb 1, 2021 · 6 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Feb 1, 2021

Divergent Getters and Setters

  • We feel like set foo(val: string), get(): Promise<string> is suspect - should getter be subtype of setter?
    • Does it really take string | Promise<string>>?
  • Non-subtyping alias unsoundness if you permit unrelated types.
  • Being able to re-assign to self seems like a good property.
  • We will be going with getset for now.

where constraint syntax

#42388

  • Idea: additional checks are to not participate in inference.

  • Validation between type parameters.

  • The syntax is pretty hard - no clear separation. The where looks like it continues the current parameter list.

    • such that
    • wherefore art thou type parameter T
  • What's the difference between this and C#?

    • We have the notion that every type parameter has a constraint.

    • Those constraints inform what you can do with values of that type parameter.

    • What do these where constraints imply about their values?

      function foo<T where T extends string>(x: T) {
          let a: string = x; // allowed?
      }
    • Unclear. T, U, T extends U could be surprising.

    • Also, we do inform the inference process using the upper bound constraint.

  • It is strange to have a notion of constraints that don't communicate anything about the upper bound.

  • What are we trying to model?

    declare function assertEqual<T>(actual: T, expected: T): boolean;
    
    declare function freeFind<T>(haystackArray: T[], needleElement: T): boolean;
    • These seem like they're just looking for comparability - just performing equality checks.
    • Also, nothing wrong with them.
  • Okay, mutable collections and elements.

    declare function freePush<T>(arr: T[], newElement: T): T[];
    
    const numArray = [1, 2, 3, 4];
    freePush(numArray, "hello" as string | number); // oops
  • Really want to model "don't infer a type from this position."

@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Feb 1, 2021
@DanielRosenwasser
Copy link
Member Author

@RyanCavanaugh what's a good link to divergent getters/setters?

@treybrisbane
Copy link

@DanielRosenwasser Just out of curiosity, what's the criteria for getting an issue to be discussed in one of these sessions? Is it just random? "Looks interesting" to one of the team? Popularity in terms of votes/something else? Maybe issue creation time, even? 😛

Assuming it doesn't already exist... Is there any potential for a periodic (monthly, quarterly, etc.) community vote on suggestions for the team to discuss?

Such a vote may help surface some of the more niche suggestions, and perhaps even get them into "Accepting PRs" status. It could also be a good way for the community to get the team's actual thoughts on some of the more, uhh, interesting features, e.g. higher-kinded types, decorators changing class type structure, nominal types, compiler plugin API, etc.

Thoughts? 🙂

@ShuiRuTian
Copy link
Contributor

@treybrisbane
Not clear about other things, but I am pretty sure that you could contribute PR to any issues with any label, even bugs or just suggestion. This would absolutely attract TS Team's attention.
And... Could I ask a question? Why are all people curious about HKT? What magic could it bring? Does it have a clear syntax, especially on how to add constraint and compatible with infer keyword?

@RyanCavanaugh
Copy link
Member

what's the criteria for getting an issue to be discussed in one of these sessions? Is it just random?

Most weeks it's "issues that caught the organizer's eye", but we rotate criteria and review highly-upvoted suggestions regularly; usually the outcome is "We still can't / don't know how to without tanking performance / don't like the implications of doing this" and no notes are taken.

We're looking at ways to make this more community- and data-driven without encouraging artificial behavior.

@treybrisbane
Copy link

@ShuiRuTian

Not clear about other things, but I am pretty sure that you could contribute PR to any issues with any label, even bugs or just suggestion. This would absolutely attract TS Team's attention.

Sure. But most of us have very limited free time, and it can be difficult to justify investing that time into PRs that the team may not accept or have time to review. Having issues explicitly marked as "Accepting PRs" means any time investment on the community's part is no longer a gamble. 🙂

And... Could I ask a question? Why are all people curious about HKT? What magic could it bring? Does it have a clear syntax, especially on how to add constraint and compatible with infer keyword?

That's a very deep rabbit hole that we probably should not go down in this thread. 😅

@treybrisbane
Copy link

@RyanCavanaugh Thanks for the reply. Makes sense. Keen to see what you come up with! 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

4 participants