Skip to content

Support destructuring in function arguments #1881

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

Closed
marijnh opened this issue Feb 22, 2012 · 6 comments
Closed

Support destructuring in function arguments #1881

marijnh opened this issue Feb 22, 2012 · 6 comments

Comments

@marijnh
Copy link
Contributor

marijnh commented Feb 22, 2012

Basically, allow things like fn foo((a, b): (int, int), @u: @something) {}.

We talked about this in the Toronto meeting. I was surprised that no issue existed for it.

@ghost ghost assigned marijnh Feb 22, 2012
@Aluminium95
Copy link

Would enum and record support destructuring in function arguments too ?

@brson
Copy link
Contributor

brson commented Feb 23, 2012

Do we really need this? I know that occasionally I have thought it would be nice to have, but we have lasted this long without anybody complaining loudly about it, so it doesn't seem vital.

@marijnh
Copy link
Contributor Author

marijnh commented Feb 23, 2012

It'd be consistent. I occasionally find myself wanting to use this -- mostly for tuple arguments.

@brson
Copy link
Contributor

brson commented Feb 23, 2012

I wonder how it would interact with our various argument modes. Does it effectively turn them all into copies? Is it only compatible with certain modes?

@marijnh
Copy link
Contributor Author

marijnh commented Feb 23, 2012

Hm. I assumed that regular modes (non-copy/move) would be able to just create views into the existing value without copying, since such args are immutable locals, but I guess if that value has mutable components, this would mess with the invariant that locals don't get their values changes from under them.

For by-copy and by-move the story gets even more involved. Maybe you're right that we shouldn't bother.

@marijnh
Copy link
Contributor Author

marijnh commented Feb 28, 2012

I'm closing this. If someone feels strongly about supporting this, discuss.

@marijnh marijnh closed this as completed Feb 28, 2012
@marijnh marijnh removed their assignment Jun 16, 2014
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Remove old action file since it's in a new repo now. I also updated our release workflow to check the new repo instead of this old file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants