Conversation

terminology:

0% [T] is a slice
0% &[T] is a slice
100% both
0% neither
6
0
0

@Mara
slice šŸ¤ logarithm

"if i don't specify you should just Know the one i'm talking about"

0
0
0

@Mara
both are slice
[T] is "slice, like the actual slice" if required
&[T] is "ref slice" if required

1
0
0

@Mara I feel like, in general, a "slice" is a view into data that specifically doesn't imply ownership. If you have a [T], you own the Ts, and it's something (I think) you don't deal with much in Rust unless you're doing weird (probably unsafe) internal voodoo.

1
0
0

@Mara

@buffet@chaos.socia
approved with option to remove the "like"

0
0
0

@Mara
In my head, [T] is a "dynamically sized array", &[T] is an "immutable slice" and &mut is a "mutable slice".

0
0
0

@Mara struct DynSizedStruct { my_ts: [T] } demonstrates that [T] isn't a slice of something else, it can be the whole gosh darned thing.

0
0
0
@d2718 @Mara You sometimes use boxed slices (Box<[T] >) which saves a bit of space compared to a vec.
1
0
0

@erk @Mara Yeah, and sometimes you'll used a Box<str>, too, but like I said, I feel like that's generally pretty rare.

We use the term "boxed slice" for that, I think, because "array" is already in use for something slightly different, but I really think [T] is more akin to an array than a slice. You own that chunk of Ts; you're not just looking at it.

0
0
0

@Mara [T] is the slice type. &[T] is a reference to the slice type, but it's so common, everyone calls it a slice too (including me).

I think it's just the fact that reference in &[T] is not the important bit, it's just a way you can accept a slice into the function. If I say "slice" it may refer to [T] inside the &[T] and & is just there too yk.

And also the fact that &[T] is the default way of working with the slice type...

1
0
0

@wffl @Mara valtrees don't even treat references as anything that exists. `(5, 6)` has the same valtree as `&&(&5,&&6)`

0
0
0