 This time around we're going to be doing a similar thing to last time, but with operators. There's a little bit extra you would need to know when dealing with that. That being said, this video is going to be much shorter because I'm not going to rehash how this approach works. If you haven't yet, if you don't know what I'm talking about, you definitely need to watch my previous video on the subject. I will have a link down in the video description just to make it easier to find. But it is on how function overloading in F-sharp is in fact possible through abusing F-sharp's type resolution algorithm. If you don't recognize what you're seeing on screen right now, definitely watch that video. For those of you who do get what's going on, or who have watched that last video, I'm going to be building up from where we left off, but instead going to be adjusting this to handle a operator that's already been defined in a way that does not hide the fact that it's already been defined. So what do I mean by this? If we can get rid of this, we have 2 plus 3, of course this has already been defined, it's your addition operator. All of this is just random junk now, so let's still run this just to show what the behavior is. We get 5. Makes sense, right? 2 plus 3 is 5. That's normal addition. Let's say you want to provide, just as a convenience thing for internal use, please do not do this for public facing code. The function overloading stuff makes sense. What I am showing off here, please do not make public facing in your library. If you're working on an app, feel free to do it there because your app isn't going to be called by other code. At least not directly, you might do something like GRPC or whatever, but you know what I mean. If you're doing this in a library, it can make sense for internal convenience, but please do not make this public facing. There are pitfalls, I will not cover them in this video, just know that I have tested this to see exactly where the issues are, and oh boy, will you hit them in public facing code. Let's define the new operator. Uh, yes, I need to make that inline. So then we have, let's just say A, and we'll give it the generic types just like before, and we'll return C. And I don't know why I did that, to be perfectly honest, because I can actually just do that here. And we're going to rename these to ADD, and you're going to be called ADD. All of you are going to be called ADD, and you get called ADD, and you get called ADD, and I'm going to keep that binder still. I haven't really come up with another name for this, just because I don't do this, for the most part. There's one example where I do this. Yeah, so I'm going to keep that binder, obviously this stuff needs to be renamed, so let's just wipe that out completely. We're going to have a static member, and this time around we're going to make it an N32, but this one will make it a, I don't know, N16. Those of you who work with F-sharp a lot know that you can't do that. It's not like C-sharp or Visual Basic where it will cast appropriately, and do that. F-sharp doesn't do automatic casting. That's why I say that this kind of makes sense as a convenience thing. You can set this up so that it does the automatic casting through a different means. So we've got that, we need to do A plus B, and you can say that it's complaining, because of course we can't do that, and you have to cast that. Now I need to remember how to do this, because this is not something that you do a lot in F-sharp. That's not it. This one? It's not. I need to look this up! Okay, apparently that's because what I'm trying to do has to do with polymorphism specifically, and this is different. So if we do that, now that works. Okay, good. So obviously, just like before, it's complaining a little bit about how that makes it this less generic, because this is resolving to a very specific thing, because there's only one of these. So let's define another one. This time, we'll take an int8, and we'll do the same thing. So now, as long as we have an int32 on the left side, we can have an int16 or an int8 on the right side, and it will still do proper addition. So, you can see that it's complaining here. I do have a solution for this that is a lot easier than what you might be thinking. But for now, let's get the... what is it? Short? And then that works. And then if we do... what's... what's for that? Does it never work with 8-bit types? B? No, I need to look this one up, too. Hold on, guys. That's because it wants Y for byte. Makes sense, actually. Just not the first thing I would try, but it makes sense. See, we can run these. And sure enough, you get what you think. Now, what might be the most obvious thing to do is... Oh, boy, that's not getting happy. So, I gotta refresh this just because the extension that is supplied for working with F-sharp gets kind of stupid sometimes. But... there we go. So, this might be the obvious thing. And it works, kind of. It's the Todd Howard kind of works. Works. We can run this. And we get what we're supposed to. Where we run into problems. That's clipping off the screen again, but you're getting the same thing that happened last time when this also happened. I'm not going to put this screenshot in in post because it's just the same thing. It's trying to find one of these and can't find it. It doesn't know to fall back to the already-defined addition operator. This also means if you try to do something like... Which... oh, my God, does that work? Wait, what? No, okay, I am very confused by this one. That shouldn't... Okay, inevitably this happens when you're abusing the type system the way that's going on here. I don't know what's going on there. I don't know. So we're going to find out. I'm going to comment that out and we're going to run this and... oh, no. Okay, it is rightfully complaining there because this isn't defined for string. So why does that make it... Okay, so we're going to find some stuff out together. Because this is neat. Let's define that for float. Again, this is not how you ideally want to do this. And I will show you how to properly deal with this after. Is that because this is supposed to be double? I forget exactly what these type aliases are. No, you still complain. I think I'm going to use format string. Because this is supposed to be different. Let me look up my F sharp print F format string things. That's why. Also, apparently these should have been I and I'm surprised they worked with D. So that's interesting. D might be decimal. Which I guess makes sense since I could cast. But F sharp doesn't normally do casting. So that's interesting. Okay, so that might have been a bizarre instance of the way format strings work. Going absolutely haywire. Seemed like it was trying to consume all of this as part of the format string as well. Which now that it can correctly resolve this isn't messing up. Format strings are a hack. If you didn't know that, they are absolutely a hack. Oh no, we're still kind of getting that though. But it is complaining about the right thing this time around. Clearly you can see that adding in all of the previous types is just cumbersome. And it's error prone and it's very easy to forget one of them. Especially in an odd case like this where addition is also defined as string concatenation. I don't know why they didn't use the list concatenation operator for string concatenation. That makes a little more sense to me. But okay. What works a little bit better is despite how much we have been fighting the F sharp type resolution algorithm. Let's work with it. Yeah, let's let let us let it do its thing. Having trouble saying that one. Just flat out remove the types there. And I think... Nope, we're in into a problem. So if we explicitly say that these are generic. Nope, you still complain. Interesting. Maybe that's an instance of some of the absolute fuckery I have going on here. I have seen this work correctly when these are method calls. And then you have the operator at the very end. So we are learning together. Again, I cannot stress this enough. This is trickery. This is black magic. This should not be the thing you jump immediately to. Because even I who understands how this works still still gets surprised. Yeah, I'm just going to leave it at this. I'll reiterate what I have said. This this approach is problematic for a lot of reasons. Please don't do this unless you have to. And if you have to, please don't make it public facing. There are a lot of odd problems. Because we are quite literally fighting the way this is supposed to work. If these are method calls. I have seen this resolve just fine. That is specifically the thing that I am doing in another code base. But apparently, if these are not method calls, then this doesn't resolve correctly. I don't know. That is how you do the operator overloading. It's almost the same thing. That's why this video is so much shorter. Please don't do this unless you have to. I'm just going to leave it at that. Have a good one guys.