that the password rule has this password default method call. What's actually happening here is behind the scenes this is going ahead and plucking out some sensible defaults like a minimum character length for your password, but what you can actually do with this rather than doing something like min 3 and then max 20 or whatever password rules you wanted to enforce, you can

fluently chain onto this password object what you want to see. So for example you could say min of you could say that you wanted this to be mixed case, you may want to check for compromised passwords in which case you can use uncompromised. There's a bunch of things that you can do with this, this isn't what has recently been added but we have a very similar thing now for email.

So if you weren't aware of that already, there we go, we've learned something else as well. I'm going to return that back to defaults and now we're going to look at the email fluent rule that's been added. So what we can do here is we can say rule and email or we can just say rules and email and from here we can just continue to chain on any of the usual things that we would

use to modify this email rule. Now actually just before we do that let's go ahead and look at what we would normally see. So for example what we could do is use DNS to do a DNS lookup on the domain. We can also use things like strict to enforce the validation of the actual email itself more strictly against an RFC. All of these are kind of optional but if you are using these you

can now do this fluently rather than using the colon and then having a comma separated list and this tends to read a little bit better as well and it kind of makes a little bit more sense. So let's go ahead and say rule and email and I'll show you, let's just do the MX record first of all. So validate MX record is the DNS flag that we just looked at. Basically what

this will do is it will just look up and make sure the domain is actually available for email just to give you that extra level validation. So this is going to work in exactly the same way. Let's go ahead and try and register an account here. I'm going to do this at a silly domain which we know doesn't probably exist and you can see here the email field must be a valid email

address. This will actually send a request now to go ahead and look this up. Now that functionality isn't new but we now have a fluent way to do this so it's a little bit clearer. We can also go ahead and use strict as well which will use that strict value that we provided before as a string to validate this a little bit more strictly according to a certain pattern. Of course you can play around

with these. This is really only useful if you're already using these because you can now do this fluently, read a little bit better and it's a little bit easier to add to if you need to. So there we go. I'm sure some more of these will pop up in future for other validation sets but for now that is the new fluid way to define email rules in Laravel.