Call for Ideas: Shaping the Architecture of OCCT 8.0.0

The Road to OCCT 8.0.0

As we ramp up development for Open CASCADE Technology 8.0.0, we are looking at a unique opportunity. Major releases are the right time to introduce breaking changes that improve the long-term health, performance, and usability of the library.

We have our own internal roadmap for modernization (C++17, infrastructure changes, etc.), but we want to ensure we are addressing the pain points that you—the community developers—face daily.

What we are already considering

To give you an idea of the scope, here are some architectural changes currently on the table:

• Standardization: Migrating from Standard_Failure to std::exception for error handling.
• Modernization: Implementing STL-compliant iterators for NCollection containers to support range-based for loops and standard algorithms.
• Cleanup: Removing deprecated math wrappers (Abs, Min, Max) in favor of std:: equivalents.
• Renevew: Update TopoDS_TShape elements with modern approach
• API Consistency: Addressing long-standing inconsistencies in naming conventions and method signatures.

We want your input

If you could change one thing about the OCCT architecture that requires breaking backward compatibility, what would it be?

We are looking for feedback on:

• API Design: Which classes or packages are the most difficult to use or inconsistent?
• Performance: Where do you see the biggest bottlenecks that might require architectural changes to fix?
• Modern C++ Integration: What C++17/20 features would significantly improve your workflow if OCCT supported them natively?

Please share your thoughts, specific examples, or even pseudo-code below. Let's build a better foundation for the future of Open Source CAD.

GitHub Discussion: https://github.com/Open-Cascade-SAS/OCCT/discussions/893