Unfortunate definition of predefined types

[PatrickHaecker]

The unconditional definition of (256, 512, 1024) is unfortunate.

1. there are a lot of cases, where they are not needed, as BitIntegers.jl has two major use cases, i.e. larger integers and non-power-of-2-but-multiple-of-8 integers (like Int24), and only the former one needs them
2. it leads to inconsistent fully qualified names, i.e. BitIntegers.Int256, but UserModule.Int24 which confuses the user

If a breaking release is done, please consider to drop this unconditional definition.

Alternatively, a package option could be introduced whether they should be loaded or not. This would even work without increasing the major version number.

[Moelf]

both of these can be sidestepped by selectively importing identifiers into namespace (e.g., using BitIntegers: ...), or re-exporting things from user module:

module UserModule
using BitIntegers: Int256
export Int256

...
end

[PatrickHaecker]

Thanks for the proposal. This mitigates the first problem. This way, however, everyone with these uses cases needs an auxiliary module or we need two packages instead of one, which is possible, but not very convenient.

Maybe I misunderstood the problem, but I do not think that this solves the second problem. I think the problem is not solvable by user code, as the macro gets executed as soon as BitIntegers is loaded independent of which symbols are brought into the namespace (of the current module or an auxiliary module).

julia> module UserModule
       using BitIntegers: Int256
       export Int256
       end
Main.UserModule

julia> import .UserModule

julia> UserModule.Int256
BitIntegers.Int256

As you can see, the last value still displays BitIntegers.Int256 as this is where the macro gets executed.

This being said there exist many larger problems in programming than this one. Nevertheless, I still think it would be cleaner if the user would specify what they need and would not get an rather arbitrary-looking predefined selection which in some use cases is not useful at all.

[Moelf]

As you can see, the last value still displays BitIntegers.Int256

right, and I guess the question is why does it matter what it displays? Is there any execution/practical implications?

[PatrickHaecker]

It does not matter too much. It's only a bit confusing that types like Int255 can be defined in any module with EmulatedBitIntegers.jl and types like Int256 are always defined as BitIntegers.Int256. We could, of course, define an additional Int256 type outside of BitIntegers, but having two Int256s is probably even more confusing.

But looking from another angle: You seem to be hesitant to the proposed change. Which problems do you see if BitIntegers.jl would no longer define these types per default or would at least provide an option to no longer define these types on package loading?

[Moelf]

Which problems do you see

mostly it's gonna be a breaking change, that's all, it's a social friction nto a technical one

[PatrickHaecker]

Ah, understood, good point.

I just checked and I think the proposal is worded in a balanced way:

If a breaking release is done, please consider to drop this unconditional definition.

So if there is a major release anyway, I think it makes sense to do this change. I do not think that this change alone warrants breaking compatibility. In this sense the added social friction should be as small as possible.