Skip to content
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

Support Incomplete Types, somehow #3180

Closed
ingo-loehken opened this issue Nov 14, 2022 · 2 comments · May be fixed by #4383
Closed

Support Incomplete Types, somehow #3180

ingo-loehken opened this issue Nov 14, 2022 · 2 comments · May be fixed by #4383
Labels

Comments

@ingo-loehken
Copy link

ingo-loehken commented Nov 14, 2022

Hi,

I'd like to come upwith a requirement to support the combination of fmt with incomplete types, that have been specialized in formatter.

To clarify the use case, an example might help

class IncompleteType;

namespace FmtHelper
{
  fmt::appender FormatTo(fmt::appender out, IncompleteType const&); // resides in linked code
};

namespace fmt
{
   template <typename charT> 
   struct formatter<IncompleteType, charT, void>
   {
        template <typename ctxT>
        constexpr auto parse(ctxT& ctx) -> decltype(ctx.begin())
        {
            return ctx.begin();
        }

        template <typename ctxT>
        constexpr auto format(IncompleteTypeconst& x, ctxT& ctx) noexcept
        {
            return FmtHelper::FormatTo(ctx.out(), x);
        }
   };
};

Rationale

  • IncompleteType injects evil headers (i.e. WinApi or others).
  • IncompleteType is from a 3rdparty lib
  • IncompleteType should be usable in headers in combination with fmt, without the need to have full type knowledge, thus usage is not in implementation files only.

Limitations

  • it is ok, to have only support for the standard format_context and buffer, therefore fmt::appender is enough and other overloads may be added, if requirements arise.

Currently

  • it is not possible to do it in that way, because type reflection vi is_base_of for compile time strings and sophisticated noexcept specifier reflection dont allo to use incomplete types.
  • im am fully aware, that this is not a common use case and the requirement comes more from productive environments with extremly huge and divers code bases and tech stacks, including microsoft specific extensions like c+/cli and others.

Workaround

  • we currently wrap such types in another type, whcih is fully known at compile time and redirects to the implementation, but this requires client code to wrap such arguments and thats not that "nice".

godbolt: simulation

@vitaut
Copy link
Contributor

vitaut commented Nov 18, 2022

I think the completeness of a formattable type is a reasonable requirement and with modules most of the rationale for supporting incomplete types goes away. That said a PR to relax this requirement would be welcome provided that it's not too intrusive.

@erinacio
Copy link

erinacio commented Aug 4, 2023

This may still be valuable for implementing formatters for types from C libraries. Many C libraries only provide struct declarations in their public header files to hide implementation details. They make all public APIs work with pointers so that a definition is not needed. Modules can't be a solution here since C has no idea about modules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants