Skip to content

Conversation

@hjmjohnson
Copy link
Member

STYLE: Simplify std::complex wrapping

  • STYLE: Remove outdated comment related to old swig versions.
  • ENH: Only support std::complex supported by c++
  • ENH: Remove of old stdcomplex adaptor code

PR Checklist

Simplifies the code and prevents std::complex
for that are not supported by c++.

•  cppreference std::complex (template parameter requirements):
   Notes that behavior is unspecified (and may fail to compile) if T is not
   a (cv-unqualified) floating-point type.  

•  Apache STDCXX user guide <complex> (older but explicit):
   States the template argument “must be” one of
      - float,
      - double, or
      - long double

Non cv-qualified types may compile on some standard libraries, fail on
others, and semantics are not guaranteed by the standard. The only fully
supported specializations are the floating-point ones.
This code seems to no longer be needed with newer
swig wrappings.
@github-actions github-actions bot added the area:Python wrapping Python bindings for a class label Jan 29, 2026
Copy link
Member

@dzenanz dzenanz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good upon cursory review.

else:
assert (
False
), f"Unknown stdcomplex type: {typedef.name}, only D and F are supported."
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
), f"Unknown stdcomplex type: {typedef.name}, only D and F are supported."
), f"Unknown stdcomplex type: {typedef.name}, only LD, D, and F are supported."

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dzenanz I did into want to change this. I am looking at removing all LD support.

Implications for an automated wrapping pipeline (e.g., ITK/CastXML/SWIG)

Conclusion from references:
• SWIG’s own documentation does not support long double out of the box and treats it as unsupported. 
• There is active ongoing concern in the SWIG community about long double handling. 
• Scripting languages (Python, etc.) map floating types to double, not long double, so the practical utility of exposing long double wrappers is low. 

Therefore, the conservative/widely practiced advice is:
• Do not generate SWIG bindings for long double automatically.
• Prefer double versions of functions if available.
• Only expose long double if you write explicit custom typemaps and verify target support.

This is effectively equivalent to a blacklist approach for automatically wrapping long double in a general automation pipeline.

Copy link
Member

@thewtex thewtex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Hans!

@thewtex
Copy link
Member

thewtex commented Jan 29, 2026

\azp run ITK.macOS.Python

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

Labels

area:Python wrapping Python bindings for a class

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants