Uh oh!
There was an error while loading. Please reload this page.
Conversation
erickt
commented
Dec 3, 2012
Cool! Does this copy the subset of the vector, or is it a slice subset? If a copy, how much harder would it be to change this use slices? |
ghost
commented
Dec 3, 2012
@erickt They're slices. |
graydon
commented
Dec 3, 2012
Definitely still interested in this being part of the language. This is great. The only thing that stands out is that I think we'll want slightly different syntax than the bit written in the RFC. Specifically: a |
graydon
commented
Dec 3, 2012
Oh, maybe a couple other substantial nits in the implementation. Lemme see.. |
graydon
commented
Dec 3, 2012
That's all I can see. Probably someone else familiar with the compilation of patterns should also take a look, but over all this looks like excellent work. Thanks so much! |
ghost
commented
Dec 3, 2012
@graydon Thanks for the review! I'm fine with a different syntax. I'm finishing off the pattern usefulness logic, will add a few tests for parsing errors (just noticed there aren't any) and resubmit. |
erickt
commented
Dec 3, 2012
What about destructuring from the beginning, such as |
ghost
commented
Dec 3, 2012
@erickt It would be fairly easy to add. I could imagine use cases for [foo, ..bar, baz] such as is_palindrome(). What I like about only having the [head, ..tail] variant as opposed to both [head, ..tail] and [..init, last] is that it encourages you to always process your data from left to right which makes code easier to read. |
ghost
commented
Dec 3, 2012
However, since this works with vectors where the (head, tail) destructuring isn't really any more natural or cheaper as in lists, I guess we could have both. :) |
ghost
commented
Dec 4, 2012
This should now be finding unreachable arms and determining whether or not the whole arm set is exhaustive. Will look at the lifetime issues tomorrow. |
bstrie
commented
Dec 4, 2012
What an awesome surprise! Does the exhaustiveness example that you posted in the issue work? Didn't see a test case for it, and in fact I'm not even 100% sure that it's possible to prove that this sort of thing is exhaustive in general. :) |
bstrie
commented
Dec 4, 2012
Also, does vector matching define any irrefutable patterns that would now be acceptable in assignment position and function arguments? |
ghost
commented
Dec 4, 2012
@bstrie 1) Yes, that example compiles now.
|
ghost
commented
Dec 7, 2012
I changed the alt checking code to preserve the region on the slice type but in the test I added the compiler doesn't actually complain due to what's probably the reason behind #3243. The transformation pass doesn't rely on the region and mutability information so I left it as-is. re_static is already used as a placeholder in ty::normalize_ty() for that same reason. |
ghost
commented
Dec 7, 2012
I realised this should be rebased against incoming. I'll do that after the next review pass. |
catamorphism
commented
Dec 9, 2012
Closing this since #4143 supersedes it. |
Compute data layout of types cc rust-lang#4091 Things that aren't working: * Closures * Generators (so no support for `Future` I think) * Opaque types * Type alias and associated types which may need normalization Things that show wrong result: * ~Enums with explicit discriminant~ * SIMD types * ~`NonZero*` and similar standard library items which control layout with special attributes~ At the user level, I didn't put much work, since I wasn't confident about what is the best way to present this information. Currently it shows size and align for ADTs, and size, align, offset for struct fields, in the hover, similar to clangd. I used it some days and I feel I liked it, but we may consider it too noisy and move it to an assist or command.
bench-cargo-miri: bump lockfiles
This is an initial implementation of vector destructuring as in #1844. It's not quite there yet but I'd like to gather feedback, assuming there is still interest in this being part of the language. I've added some tests, two of which are failing at the moment as there's no pattern reachability and exhaustiveness detection just yet.
As mentioned in the bug, there already is a list structure in libstd, which can already be easily destructured and matched against. It's not a first-class citizen in Rust, so it may be worth making it easy for vectors as well.