Stream: general

Topic: Explicit move for structs


Daniel Papp (Jun 12 2019 at 10:46, on Zulip):

Is there a way to move a struct which implements the Copy trait? I know that structs that don't implement the trait are moved automatically, but how can I force this behavior for the ones that do?

oli (Jun 12 2019 at 10:59, on Zulip):

That's not possible

RalfJ (Jun 12 2019 at 11:01, on Zulip):

what does it even mean to "move" something that is Copy?

RalfJ (Jun 12 2019 at 12:23, on Zulip):

IOW, I don't understand the question.

oli (Jun 12 2019 at 12:25, on Zulip):

I think the question is whether a variable can be marked as "moved out of" or "not available anymore" so that any further accesses will error

centril (Jun 12 2019 at 14:44, on Zulip):

I suppose one could theoretically support let x = move y;

centril (Jun 12 2019 at 14:45, on Zulip):

to force y to become unusable.

oli (Jun 12 2019 at 14:51, on Zulip):

seems niche enough that at best it should be an intrinsic imo

Jake Goulding (Jun 12 2019 at 15:05, on Zulip):

How to force a move of a type which implements the Copy trait?

I've never understood the question either.

centril (Jun 12 2019 at 15:11, on Zulip):

@oli seems niche enough to not even be an intrinsic imo :slight_smile:

oli (Jun 12 2019 at 15:12, on Zulip):

agreed, I was trying to set an upper limit

Jake Goulding (Jun 12 2019 at 15:12, on Zulip):

I think that (absent any other context), the right thing would be to make a newtype. This type wants different semantics from the underlying Copy type.

Jake Goulding (Jun 12 2019 at 15:13, on Zulip):

e.g. i32 can be copied, but an Identifer(i32) cannot

oli (Jun 12 2019 at 15:13, on Zulip):

Yea, Rust encodes most-if-not-all features in the type

centril (Jun 12 2019 at 15:37, on Zulip):

@Jake Goulding oh no; this is where an ECS starts =P

Jake Goulding (Jun 12 2019 at 15:38, on Zulip):

@centril entity-component system? I'm not seeing the connection...

centril (Jun 12 2019 at 15:47, on Zulip):

@Jake Goulding struct DefId(...); and stuff

centril (Jun 12 2019 at 15:47, on Zulip):

newtyping an integer like that

RalfJ (Jun 12 2019 at 16:00, on Zulip):

also as far as the typechecker goes, intrinsics are just functions, right? So doesnt seem like a job for an intrinsic to me.

RalfJ (Jun 12 2019 at 16:00, on Zulip):

if it's magic in the type system it is a syntactic language primitive. papering over that by pretending it is an intrinsic doesnt help anyone IMO.

centril (Jun 12 2019 at 16:04, on Zulip):

@RalfJ agreed

simulacrum (Jun 12 2019 at 16:05, on Zulip):

If you just want a variable to be unreadable (though not e.g. a field, I'm not sure we could support that, you can always do let y = x; let x; presumably?

RalfJ (Jun 12 2019 at 16:05, on Zulip):

intrinsics are magic in terms of their dynamic semantics (so they are primitives in that sense), but for the static semantics they should be like any odd function. transmute is an exception already (it checks that the sizes are the same) and that already has some annoying consequences (like you can't wrap it).

centril (Jun 12 2019 at 16:06, on Zulip):

transmute is an exception already (it checks that the sizes are the same) and that already has some annoying consequences (like you can't wrap it).

Hopefully temporary with some const generics

centril (Jun 12 2019 at 16:06, on Zulip):

@simulacrum

fn foo() {
    let x = 0;
    let y = x;
    let x; // error; unknown type.
}
simulacrum (Jun 12 2019 at 16:08, on Zulip):

let x: ();?

centril (Jun 12 2019 at 16:08, on Zulip):

you can do:

fn foo() {
    let x = 0;
    let y = x;
    let x = ();
}
centril (Jun 12 2019 at 16:08, on Zulip):

@simulacrum yeah but you need to initialize it also

simulacrum (Jun 12 2019 at 16:08, on Zulip):

what for? if you're specifically intending to never read from it

centril (Jun 12 2019 at 16:08, on Zulip):

or not, if you don't use it; but now you need #[allow(unused)]

rkruppe (Jun 12 2019 at 16:09, on Zulip):

The unused lint will get in your way even if you initalize.

simulacrum (Jun 12 2019 at 16:09, on Zulip):

sure, yeah, there's no real way to shadow w/o allow(unused) for this purpose (initializing it won't help)

Jake Goulding (Jun 12 2019 at 16:53, on Zulip):

I do think a move {} block would fit nicely in terms of filling out the syntax grid, but it's kind of silly (and plain {} does that now in most cases)

Last update: Nov 20 2019 at 11:25UTC