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

Allow coercions from statically sized to dynamically sized arrays #13716

Closed
nrc opened this issue Apr 24, 2014 · 3 comments
Closed

Allow coercions from statically sized to dynamically sized arrays #13716

nrc opened this issue Apr 24, 2014 · 3 comments

Comments

@nrc
Copy link
Member

nrc commented Apr 24, 2014

The following should be valid:

fn coerce1(x: &[int, ..5]) {
    let y = x as &[int];
}
fn coerce2(x: ~[int, ..5]) {
    let y = x as ~[int];
}
@nrc nrc mentioned this issue Apr 24, 2014
23 tasks
nrc added a commit to nrc/rust that referenced this issue Apr 24, 2014
This only allows them at the type checking stage. We still require implementation in trans. Also needs tests. Part of rust-lang#13716.
@aturon
Copy link
Member

aturon commented Aug 13, 2014

I wanted to clarify something about the plan with DST. Currently, we allow a third variant of the above:

fn use_slice(s: &[u8]) {}
fn main() {
    let s: [u8, ..3] = [0,1,2];
    use_slice(s);
}

In other words, we coerce from [T, ..n] to &[T]. This rule is inconsistent with our general move away from auto-borrowing coercions.

My question is: as part of the DST coercion work, are you planning to remove this coercion?

Alternatively, I wonder if it might make sense to replace this coercion with &[T, ..n] to &[T] separately from DST, just as we've been removing various other coercions like auto-cross-borrowing to front-load breaking changes?

cc @nikomatsakis @pcwalton

@nikomatsakis
Copy link
Contributor

I believe we should not coerce from [T, ..n] to &[T] but instead just &[T, ..n] to &[T] (that is, the usual sized-to-unsized coercion). It does mean that foo([1, 2, 3]) becomes foo(&[1, 2, 3]), but that seems more consistent with everything else in the language. If we wanted to address the need to write things like map.find(&3), it seems like the right way to do that is across the board with some sort of "autoref" coercion.

@nrc
Copy link
Member Author

nrc commented Sep 23, 2014

This work has landed now.

re the [T, ..n] to &[T] coercion: I agree we should remove it. That is part of a WIP RFC covering coercions which should arrive soon.

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