Skip to content

Conversation

@Graveflo
Copy link
Contributor

@Graveflo Graveflo commented May 25, 2025

offshoot of #24964

I first tried to make importc types a new kind of type and allow it to accept it's Nim equivalent, but this was difficult, took a lot of time and in the end I couldn't get it to fully work. The main problem was that Nim converts types to and from importc types regularly, so this new type had to do a bunch of odd things to not break those behaviors.

Trying this out was much easier since I could just re-use most of the logic for distinct however there are some concerns I have at this time:

  • sameType proc might need some attention
  • I haven't looked at the generated C code so it might be inefficient
    • I'd be interested to see seq[T] varients and such
  • Conversions are still needed in some situations with this where they weren't before, but so far I haven't seen anything that looked like it should work. For example a previous automatic conversion from a non literal int to cint needed a patch, but why did that work without a conversion in the first place?
    • primitive conversion semantics probably have to be looked at again but I forget where that is / how that works
  • this accepts the type both ways with equal penalties and such and I haven't really thought about if that is a mistake

in general I think that something like

type myType {.importc:"int".} = int32

always must mean that the backend will map Nim's representation of int32 to int, if this is not a guarantee then something like nodecl and a proper exclusive definition has to be used to make the type opaque and I don't think there is a way around that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant