You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CS already has nice recursive pattern matching on arrays and objects, which is fantastic. This feature works for LHS parts of assignment expressions. This feature should also work for formal parameter lists. Example:
A very nice idea, but I'm afraid we've tried to stay away from complicating parameter lists in the past. There have been proposals for named parameters, default-valued parameters, and variations of these pattern-matched parameters.
I think that the party line should continue to hold. Parameter lists should be simple lists of names, and it's up to your function body to de-structure or manipulate them as you see fit.
There's a good argument to be made that, at the point when you've specified a method signature like the above, where you're expecting a primitive array of a certain structure, followed by a primitive object of a certain structure, you should really be passing a full-blown object in, that can encapsulate that state.
So thanks for the ticket, but closing as a wontfix. There's no additional flexibility that this gives you that couldn't otherwise be accomplished by a pattern match at the start of your function (which is probably what we would transform it into, if we added it).
CS already has nice recursive pattern matching on arrays and objects, which is fantastic. This feature works for LHS parts of assignment expressions. This feature should also work for formal parameter lists. Example:
The text was updated successfully, but these errors were encountered: