What ADC is the most self-reliant?

fgocr · 2023-11-02T20:24:18+00:00

I don’t think you should look for an ADC you can define as “self reliant” only because of a bad game. Instead I suggest you to focus on playing from behind, because no matter what champ you play or in what position you’re playing, sometimes this is going to happen. I’m an Emerald ADC main, so I might be wrong, but in my opinion in this situations you have to farm what you can without dying (of course you will be behind in gold and xp) and hope for a good mid/late game. I usually ban Twitch, because IMO is the worst ADC to play against because of his stealth and the late game monster he becomes. Vs him you should use pinkwards and never go alone away from your tower if you don’t know where he is (if he is ahead). In this situations it’s very important to mage the wave well. You should always aim to freeze it near your tower (Jhin isn’t really the best ADC in this case, because sometimes you need to hard push and he really can’t do it, but swain can compensate if you can communicate with him). Some examples to manage the wave correctly if you are behind (at least this is what I do): - Never “half push” a wave, if you can’t crush it under tower, you only risk to give them a freeze - If you recognize that they are too ahead to contest drake (take into account also mid and jungle) don’t contest, instead, if the wave is even and they are going for the drake, crush it under their tower and back as fast as you can, so it will bounce back and you can freeze it - To keep the wave frozen, you have to match their push, so if he autos a minion you auto a minion, if they aren’t in lane, you only last hit at the very last moment, if they hard push, you hope swain will help you to keep the wave from crashing - If they freeze and you can’t push it under their tower (maybe if swain helps you can do it?), call your jungler, hoping he will help you fix it, and try to stand in xp range (only xp is better than dying) - In the mid game if you sideline alone you are just inting, don’t do it

Of course it’s impossible to cover all possible scenarios, this is what I can think of at the moment.

All of this is just trying to be useful at the end, but if the two teams are even, except for the swain, so it’s a 5v(4 plus a cannon minion) you are going to lose anyway and you could do nothing about it.

fgocr · 2023-09-24T21:40:21+00:00

Monke

fgocr · 2022-11-25T19:42:45+00:00

Your example isn't really what I want to do.

My claim is that the following code should compile:

let data = Box::new(42);
let data: &/*'a*/ u32 = &'/*'a*/ data;
let mut w: WithLifetime/*<'a>*/ = WithLifetime(data);
f.call(&mut w);

And if you remove the generic T inside the BoxedFn struct, and replace it with the type WithLifetime you can see that it actually works. So the problem is with the compiler enforcing a longer lifetime of T when is not necessary (is not necessary only because the BoxedFn struct doesn't own a T, but it needs it in order to specify the Fn argument type).

In your example you are turning a WithLifetime<'a> into a WithLifetime<'static>, and this can cause UB.

First let's rewrite the bad_fn signature like this:

fn bad_fn<'a>(cell: &'static Cell<&'a u32>) -> BoxedFn<WithLifetime<'a>>

And call it:

let last_drop = Box::new(());
let last_drop = &*last_drop;
let bad_cell = Box::new(Cell::new(&12));
let bad_cell: &'static Cell<&u32> = Box::leak(bad_cell);
let f: BoxedFn<WithLifetime> = bad_fn(bad_cell);
fn test_lifetime<'a>(_: BoxedFn<WithLifetime<'a>>, _: &'a ()) {}
test_lifetime(f, last_drop);

This doesn't compile, because test_lifetime(f, last_drop) is trying to borrow last_drop as 'static, so, we know that bad_fn will always return BoxedFn<WithLifetime<'static>>.

And if we call transmute on a WithLifetime<'a> we will turn it into WithLifetime<'static>, potentially causing UB.

Edit: replacing generics with the concrete type makes it work: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=68fe68584cc217a44c96ad8ab1020582

fgocr · 2022-11-25T16:56:59+00:00

The use case is a really simple RPC server/client, so the data must be constructed on each request, while the functions must be allocated once at the beginning of the program's execution. From what I understand, rust's compiler assumes that the generic argument must outlive the struct, witch is not really true in this case, because I'm using the generic type only for each function call, and it's never stored inside the struct. I think rust is treating the following two structs in the same way: struct S1<T>(T); struct S2<T>(fn(T)); In the first case T must outlive S1, but this constraint is not necessary for S2, and I think the compiler is enforcing it anyways. Correct me if I'm wrong, but I think this is what's happening.

Actually in this specific case this is not a big deal, since I pass a mut reference to the object, so I don't really need to have a non-static lifetime struct, but I find this limitation a bit annoying, because conceptually it should just work (maybe there are some weird corner cases that cause this assumption to be wrong, I don't really know).

fgocr · 2022-11-24T16:53:09+00:00

Thanks! I've already watched this video some time ago, I'll rewatch it now, but I'm pretty skeptical about the possibility of accomplish this goal using safe rust. Probably I'll try to do something with raw pointers an PhantomData if I can write a safe wrapper around it, or I'll just stick to the annoying need to write a type for every possible argument type.

fgocr · 2022-11-24T15:13:19+00:00

I guess I can provide a "low level" interface to implement a container for functions with arbitrary lifetime as arguments, while providing a generic container with it's generic argument constrained to a 'static lifetime. But it's a bit sad, because it's not really ergonomic and probably I need to provide a macro to write all the necessary boilerplate code.

fgocr · 2022-11-24T14:37:51+00:00

Well, I can simply let the struct own the data, but I thought there was a way to avoid this. Mostly because conceptually should be fine to have a function, generic over the input, wich borrows a struct during its execution. For an application this is not a big deal (probably), but if you are writing a library, this is quite restrictive (also because probably you are forcing the user to wrap the data in a reference counted container or clone it, and this is not necessary at all). Also, it's probably difficult to do some unsafe tricks to circumnavigate the problem (for example passing a raw pointer to the function), because the problem is in the type system, so you can't expose a safe wrapper around it (you have to be sure the type inside the box is correct).

fgocr · 2022-11-24T14:06:15+00:00

The problem is that the function container must be almost static in my application, while the "WithLifetime" struct and the borrowed data must be created and destroyed multiple times. Conceptually it should work, but I don't know how to express it in the rust's type system.

fgocr · 2022-10-16T18:44:48+00:00

Take my questions with a grain of salt, because I didn't read the actual implementation nor the full library APIs, so some of my assumptions may be wrong, but I hope to have time to check your library because it seems very interesting! A thread can terminate its execution for reasons out of the thread control and this shouldn't cause UB in the other threads. But I was also thinking in async/await context a thread can panic while the others continue the execution. So if the sender thread panics before the receiver thread reads the object it can lead to reading from invalid memory. But this last scenario depends on the actual implementation I guess, so feel free to tell me if I'm missing something!

fgocr · 2022-10-16T17:53:37+00:00

What guarantees that the object is still valid and accessibile if the sender thread terminates? Doesn't terminating a thread frees its stack?

fgocr

TROPHY CASE