better support for `signed` and `unsigned`

[matthias314]

Currently signed and unsigned work on types only if the target type has been declared, too. Even in that case, unsigned may error on emulated signed integers.

Defining signed integers first:

julia> @emulate Int3

julia> unsigned(Int3)
ERROR: MethodError: no method matching Unsigned(::Int3)

julia> unsigned(Int3(-1))
ERROR: MethodError: no method matching Unsigned(::Int3)

julia> @emulate UInt3

julia> unsigned(Int3)
UInt3

julia> unsigned(Int3(-1))
ERROR: InexactError: convert(UInt8, -1)

Defining unsigned integers first:

julia> @emulate UInt3

julia> signed(UInt3)
ERROR: MethodError: no method matching Signed(::UInt3)

julia> signed(UInt3(7))
ERROR: MethodError: no method matching Signed(::UInt3)

julia> @emulate Int3

julia> signed(UInt3)
Int3

julia> signed(UInt3(7))
-1

To fix the errors on type arguments, it might be necessary to create both the signed and the unsigned version of an emulated integer type at the same time. This is what BitIntegers.jl does.

[PatrickHaecker]

Thanks for the clear and detailed report.

This is a deliberate design decision. In general, we can have a lot of emulated bit integers (the number is close to infinity and only limited by resources / what can be indexed on your HW) and we can have any method which maps one emulated bit integer to another emulated bit integer. In other words: It's impossible to define all the types which might be the result of a function.

While I understand the appeal of supporting signed/unsigned, this special casing for two functions, but not for the rest, seems to be an inconsistent and mostly arbitrary approach. The design goal of EmulatedBitIntegers.jl is to only create exactly the type the user explicitly requests. In my opinion this low-level stuff is not the place to guess what the user might want to have in addition to what they have requested, but the building blocks where comfort layers can be put on top if needed. Therefore, the interface is deliberately different than the one from BitIntegers.jl.
See e.g. BitIntegers.jl#47 and BitIntegers.jl#53 for the problems this creates in BitIntegers.jl and which are or can be avoided in EmulatedBitIntegers.jl.

I can imagine, that we add another interface (@emulate 3 could work), but I think the best solution is to educate the user and possibly adding a convenience package to provide groups of useful types for certain use cases with a single call (signed/unsigned being one of it).