You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am wondering whether this is a problem when we are defining UA_XXX_delete methods that look up the correct UA type within UA_TYPES_PTRS based on the julia type.
For the string types, it would for example be quite easy to make them distinct (just copy the UA_String struct definition); for the number types, it would be slightly more involved, but I think it could in principle be done using AbstractNumbers.jl.
The text was updated successfully, but these errors were encountered:
Yes, this currently definitely leads to a problem as the user is required to add the correct type_ptrargument to the functions. AbstractNumbers.jl indeed looks promising for a nice solution.
Currently, there are a number of ambiguous types (several UA types have the same julia type), namely:
I am wondering whether this is a problem when we are defining UA_XXX_delete methods that look up the correct UA type within UA_TYPES_PTRS based on the julia type.
For the string types, it would for example be quite easy to make them distinct (just copy the UA_String struct definition); for the number types, it would be slightly more involved, but I think it could in principle be done using AbstractNumbers.jl.
The text was updated successfully, but these errors were encountered: