That was great, thank you! Amazing how it catches so many errors before even running; and, the hints are dynamic as well. Nicely demonstrated.

There is a bug in your final lock() method on lines 27 and 31, since it just returns an unlocked password manager. You should change the state to locked in both lines. Other than that minor issue, great vid.

Lmao, this was done in OOP for past 50 years.

@@shinobuoshino5066What does OOP have to do with the topic of the video? This is about encapsulation verification (access control) at compile time via Rust's type system. How does OOP do the same via types?

Good catch, it should be locked.

@@letsgetrustyI suggest to always return Self to simplify refactoring and guard against such cases for the future. One can also construct and return a Self {}.

@@mihaigalos279 Isn't Self the wrong type? If you call unlock then Self is PasswordManager but you want to return a PasswordManager

​@@mihaigalos279 can't use Self when changing the state since Self represent the type with the current state

Thank you, I thought I was going crazy.

This is definetly the proper way to solve this specific problem. Not only you get compile time checks for API usage, but your API is now closer to supporting being unlocked independently in two different functions.

@@GrzesiuG44 however, this requires allocating extra data, which isn't what the demo was trying to demonstrate.

@@tubebrocoli cannot this token be a zero-sized struct too? "struct Token;" If it can, how does passing a zero-sized struct as a function parameter affect the function's call stack?

Indeed, usage of `PhantomData` seems redundant since `State` is already a zero-sized type. (BTW, there is another error: in the third solution, the method `lock()` should return a `PasswordManager`, not `PasswordManager`.)

@@julytikh Yeah, I also noticed both errors. But the video is still great!

I'm new to Rust, but I felt weird, when he said, that just using "State" would take up memory, since Locked amd Unlocked are zero sized types, just like PhantomData. I'm glad to see, that I wasn't mistaken. What are idiomatic uses of PhantomData then? I know, it can "own" nonzero size types (e.g. PhantomData), but when is it useful compared to using just plain unit structs? The only thing I can see, is if somebody by mistake created PasswordManager (which wouldn't be prevented by compiler), they'd be wasting some memory in case, where "state: State" ("state: i32": size is equal to size of i32), as opposed to "state: PhantomData" ("state: PhantomData": size is 0). But there's a way to restrict the State generic to only include the right types, which would prevent you from creating idiotic types like PasswordManager, which would be even better, than using PhantomData to deal with it. You can create a (possibly private) marker trait yourself, let's call LockState and have Locked and Unlocked implement it, and then restrict generic State: LockState. At that point there's no need to use PhantomData in this case, and it's absolutely impossible to create idiotic types (e.g. PasswordManager). I guess PhantomData is useful in cases, where your intent is for your type to be able to be marked by any types user of your library wants (e.g. YourType, YourType, YourType). But I don't know of such scenario (because YourType would not actually contain values of those types, it's only marked by them).

@@tri99er_ One case where this comes up occasionally is when you need a type dependency for the working of your type (e.g. for a return type in one of its methods, for example) but the type isn't actually used in the struct itself. In that situation, you can use a PhantomData to satisfy the compiler that you are "using" the type in the struct so that you can use the parameter in your methods.

@@tri99er_ e.g. the implementation of 'dyn Trait'

Just make LockedPasswordManager a newtype for &mut PasswordManager. That way, it makes the locked manager avaliable after it gets dropped automatically thanks to Rust's ownership system.

u can just impl the Drop trait cant u

There's no inheritance in Rust. And traits don't have access to implementor fields, so you'll end up with the same amount of duplication.

you code your password vaults like this? 😱

Indexed Monads are an extension of "plain"-er GADTs with DataKinds. Before those were usable, people used open phantom types. GADTs + DataKinds are more common than indexed monads because a lot of operations can be represented with simple non-monadic functions.

I.e it's not like an FSM with one state but rather a struct where you can have multiple instances all with same content with different state.

That's the whole point: lock and unlock take their self argument not by reference but by ownership transfer (i.e., move). So the caller loses ownership, and there cannot be any references to the old instance or the whole thing does not typecheck.

Why? If you rename the struct shouldn‘t the IDE rename that too?

lock() and unlock() do not return Self, they change the type

I'm also confused about this. I can certainly see PhantomData being useful if the struct holds some data, but in this case there really shouldn't be any additional memory used.

I checked it on goldbolt and both structures with :State and :PhantomData takes 72 bytes for me, so I guess it is optimized out in both variants

What he is saying is very confusing, if T is a ZST you don't need PhantomData to make it ZS because it already is, PhantomData exist primarly for lifetimes: for example there are structs that owns a pointer for optimizations, but still need to hold the lifetime of the backing data, so you add somewhere a PhantomData

It wouldn't, I made a mistake. Will point this out in the pinned comment.

Enum variants can't have unique implementations, so it doesn't really solve anything at all.

Looks like the PhantomData struct is since 1.0.0. I don’t see when default generics were added but there’s a spec for it from 2015.

Actually, `PhantomData` is redundant in this particular case. The types `Locked` and `Unlocked` are already zero-sized (because they have no fields), and `PhantomData` does not improve upon that.

@@julytikh can you explain how not to use the phantom data in this example

@@LukasCobblerxD just use `State` instead of `std::marker::PhantomData`.

This would solve the problem of user building the wrong state by itself

The issue is that you can't implement different functionality on a struct based on an enum variant. Therefore, we only know if the manager is locked/unlocked at runtime, resulting in panics or results like the first solution. As he showcased, generics allows multiple implementations. The only concern I have is restricting the available State variants, since his implementation allows arbitrary types to it. Perhaps having a sealed trait would solve this as a constraint => pub type PasswordManager {}

@@ErikCampobadal You didn't understand me correctly. I'm saying turn `struct Locked;` into `enum Locked {}`, an enum with 0 veriants which is a non-constructible type in Rust.

@@Artentus ahh interesting, indeed. This combined with a sealed trait could be a great solution

Would you say this is the better approach? Is it less common?

Seems like TODO Highlight vscode extension

The todo-tree VSCode extension + adding this line to settings.json: "todo-tree.regex.regex": "(//|#|

@@letsgetrusty TY

it intentionally consumes self to prevent dangling references to previous states

This is correct, but I think it's clearer, because we are not creating a locked manager, but just a manager(Even though it will be locked anyway)

this is what I thought the video would be about

You could normally do that by implementing drop on the unlocked password manager and calling the lock method, except his lock consumes self and you only have a &mut self when implementing drop so I'm not sure. I guess in a real use case, lock would have some other functionality that encrypts the passwords and writes it to a file for example, which would be available to call in the drop implementation, so you could do that at least.

This API prevents calling lock twice while for mutexes calling lock twice (usually from a different thread) is the point. I suppose you could create a Mutex API such that each client gets issued a reference wrapped in a way that prevents lock being callable the second time on the same reference.