Hello @wiasliaw, and thank you for submitting this PR.

We currently have a request for wider type support in the SafeCast library. Exhaustive type support there calls for procedural generation. I'm wondering if that is something we would like to do here as well. @frangio ?

Hi @Amxx. Currently, map supports for uint256=>address and address=>uint256. It doesn't support bytes32=>bytes32 to let user customize. I think that SafeCast should work with casting uint256 or bytes32 to uintX or bytesX.

Thank you @wiasliaw. This type is kind of already present as the Map type though, right? I think we can just make the functions for that type internal instead of private, instead of adding an unnecessary indirection level.

@Amxx As for support for other types, I'm not really sure to be honest. I don't really like that we have all of these variations for different types. I don't trust the compiler to efficiently remove the casts and inline functions. I was in fact considering that we can only have a single type using bytes32 and let users cast to whatever type they need. This is what we did with the Deque type essentially.

@frangio I think that expose through a new struct will have more readability.
Comparing between Bytes32ToBytes32Map and Map.

Yeah possibly. In that case I'd rather we renamed the current Map to Bytes32ToBytes32Map, instead of adding an extra indirection layer that will add overhead. @Amxx What do you think?

I'd be ok to do that, but we'll also need to change _set(...) private to set(...) internal

I think we got the result of implementation. I will work on this PR.

Hi @Amxx, @frangio, renaming into _set() internal will violate the role private-vars-leading-underscore.

I meant set(...) internal, sorry for the typo.

I had done with the PR. Plz review. TKS