Skip to content

try weakened distinct #24967

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: devel
Choose a base branch
from
Open

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant