Skip to content

Add opt-in support for custom string types - #306

Open
mikomikotaishi wants to merge 1 commit into
marzer:masterfrom
mikomikotaishi:master
Open

Add opt-in support for custom string types#306
mikomikotaishi wants to merge 1 commit into
marzer:masterfrom
mikomikotaishi:master

Conversation

@mikomikotaishi

Copy link
Copy Markdown
Contributor

What does this change do?

This PR adds support for custom string types through an opt-in toml::string_like<T> specialisation (inherit std::true_type to enable), as long as it can be convertible from std::string/std::string_view, and can be constructed from const std::string&/std::string_view (also std::string).

template <>
struct string_like<java::lang::String> : std::true_type {}

Is it related to an exisiting bug report or feature request?

While I haven't found any issues specifically requesting support for non-std string types, I suppose #175 is a related issue. The intention is to allow custom string types to be usable with the library, however it must be opt-in (not simply inferred), to prevent things like std::filesystem::path from being detected as "string-like" (i.e. std::is_convertible_v<std::filesystem::path, std::string_view>).

Pre-merge checklist

  • I've read CONTRIBUTING.md
  • I've rebased my changes against the current HEAD of origin/master (if necessary)
  • I've added new test cases to verify my change
  • I've regenerated toml.hpp (how-to)
  • I've updated any affected documentation
  • I've rebuilt and run the tests with at least one of:
    • Clang 8 or higher
    • GCC 8 or higher
    • MSVC 19.20 (Visual Studio 2019) or higher
  • I've added my name to the list of contributors in README.md

/// conversions at the API boundary only, not the underlying storage, so retrieving a value as a
/// user-defined string type makes a copy.
template <typename T>
struct string_like : std::false_type

@marzer marzer Jul 28, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

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

Hi, thanks for the contribution. I can see the desire for this, but to be honest I'd much prefer an inferred model, as this is inline with nlohmann::json and other common libraries in this domain, where they detect 'string-likes'.

The basic principle would be to detect types that:

  • have public const char* data() const or const char* c_str() const
  • have public size_t length() const
  • (optionally) not implicitly convertible to string_view (to avoid ambiguity).

These sorts of checks should be pretty trivial to write with some expression SFINAE (is_detected or similar).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

OK, I can try and look at nlohmann::json's implementation and apply it here.

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.

2 participants