`drop` without `Drop`

[AiyionPrime]

Hey @einarmo? What is the drop statement in line 73 supposed to do there?
Doesn't that only work on types implementing Drop?

The type of activate_fut is
std::pin::Pin<&mut impl futures::Future<Output = std::result::Result<client::session::connect::SessionConnectMode, types::status_codes::StatusCode>>>,

which is not Drop; does this do something I just don't get?

opcua/lib/src/client/session/connect.rs

Lines 44 to 73 in 8cc43e5

	let activate_fut = self.ensure_and_activate_session();
	pin!(activate_fut);
	let res = loop {
	select! {
	r = event_loop.poll() => {
	if let TransportPollResult::Closed(c) = r {
	return Err(c);
	}
	},
	r = &mut activate_fut => break r,
	}
	};
	let id = match res {
	Ok(id) => id,
	Err(e) => {
	self.inner.channel.close_channel().await;
	loop {
	if matches!(event_loop.poll().await, TransportPollResult::Closed(_)) {
	break;
	}
	}
	return Err(e);
	}
	};
	drop(activate_fut);

[einarmo]

I think I did this because it didn't compile at some point, but it seems fine now, I can't remember why I did it now. You sometimes get this kind of error, where the default drop-order of values in a method causes a compiler error. The compiler is almost always smart enough to realize that it can drop values early, but you occasionally get an error which requires you to manually drop a value before the end of the function. That might have happened here.

As for your question, std::mem::drop works fine on types that don't explicitly implement Drop. Every type has a destructor, which recursively calls drop on all its members, drop ends up invoking that.

Drop isn't the destructor, it's more like a callback that runs before the destructor runs. Confusingly we just call destroying a value for "dropping" in rust.

[einarmo]

This specific instance of drop can be removed, unless it causes issues.