Skip to content

[Core] Add KRATOS_DEPRECATED_ERROR macro for compile-time deprecation enforcement#14466

Open
loumalouomega wants to merge 1 commit into
KratosMultiphysics:masterfrom
loumalouomega:core/adding-Kratos-deprecated-error-macro
Open

[Core] Add KRATOS_DEPRECATED_ERROR macro for compile-time deprecation enforcement#14466
loumalouomega wants to merge 1 commit into
KratosMultiphysics:masterfrom
loumalouomega:core/adding-Kratos-deprecated-error-macro

Conversation

@loumalouomega

Copy link
Copy Markdown
Member

name: ✨ Feature
about: Add KRATOS_DEPRECATED_ERROR macro for compile-time deprecation enforcement.


📝 Description

Adds a new macro KRATOS_DEPRECATED_ERROR to kratos/includes/define.h that causes a compile-time error once a specified deadline date is reached. This complements the existing KRATOS_DEPRECATED_MESSAGE (which emits a deprecation warning) by providing a hard enforcement mechanism: code marked with this macro will simply refuse to compile past its deadline, ensuring deprecated APIs are actually removed.

Fixes #14461 ?

Typical usage

Inside a function body, at class scope, or at namespace scope:

// Warn users at call sites (existing mechanism)
KRATOS_DEPRECATED_MESSAGE("Use NewFunction instead")
void OldFunction() {
      // Fail compilation once the deadline is reached (new mechanism)
      KRATOS_DEPRECATED_ERROR(2026, 12, 31, "Remove OldFunction and update all callers.");
      // ... old implementation
}

When the deadline passes, the compiler emits a clear error pointing to the macro call site, including the deadline date and the developer-supplied message:

error: static assertion failed: DEPRECATED [deadline: 2026-12-31]: Remove OldFunction and update all callers.
note: the comparison reduces to '(20270103 < 20261231)'

Key changes

  • New macro KRATOS_DEPRECATED_ERROR(year, month, day, message) added alongside KRATOS_DEPRECATED and KRATOS_DEPRECATED_MESSAGE in kratos/includes/define.h. Expands to a static_assert that compares the compile date against the given deadline. The assert fires on the dead line day itself (strictly <).
  • Three constexpr helpers added in a new namespace Kratos::Internals block inside the existing namespace Kratos section of define.h:
    • DeprecationMonthToInt(const char*) — maps the 3-letter month string from __DATE__ to an integer 1–12.
    • CompileDateAsInt(const char*) — parses the __DATE__ predefined macro ("Mon DD YYYY") into a YYYYMMDD integer for comparison.
    • DeadlineDateAsInt(int, int, int) — packs the (year, month, day) macro arguments into the same YYYYMMDD format.

No changes to CMake, Python bindings, or application code are needed — the macro is purely a header-level addition and the constexpr helpers are zero-overhead (evaluated entirely at compile time).

Validation

  1. Future deadline (2099-12-31) — compiles without error.
  2. Past deadline (2020-01-01) — produces the expected static_assert error with the correct message and comparison values printed by the compiler.

🆕 Changelog

@matekelemen

Copy link
Copy Markdown
Contributor

As I mentioned in #14461, the problem with this approach is that we'll never be able to compile earlier versions (unless someone resets their system time or changes this macro).

@philbucher

Copy link
Copy Markdown
Member

this was rejected in the past bcs users would just start to meddle with the systems time etc. Imagine how annoying this would be to use on a cluster. You want to run the final sims for your phd project, and then get hit with such an error because somebody refactored sth

@loumalouomega

Copy link
Copy Markdown
Member Author

this was rejected in the past bcs users would just start to meddle with the systems time etc. Imagine how annoying this would be to use on a cluster. You want to run the final sims for your phd project, and then get hit with such an error because somebody refactored sth

yes I remember, but I don't have any other idea...if you have a better suggestion we can use this as base

@philbucher

Copy link
Copy Markdown
Member

I think the only way is to have depreciation warnings telling the user what to do

Depending on what changes dictates the deprecation period.

IMO large things like elements in major apps should remain for at least half a year

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Discuss about how to deprecate elements/conditions/features

3 participants