@albanD I understand the concern of users accidentally overflowing an int32 tensor, however the requirement of int64 is causing issues for many people integrating with 3rd party inference engines like TensorRT and OpenVino. You can see the long history on this Github issue 2 which has been open for almost 5 years!
I think providing full compatibility is a bigger concern than potential user errors, especially if int32 behavior was designed so that it’s only enabled on an explicit call like torch.tensor(dtype=torch.int32). Then basic users will not find themselves in the overflow situation. Another option would be to put this under a different class name like nn.SmallEmbedding which again forces users to make an explicit choice where they are aware of the potential downsides.
Could the team please re-consider the priority of addressing this or provide a road map for community members to contribute this feature in a PR?