Skip to content

Rewrite container parsing#61

Open
yaito3014 wants to merge 47 commits intomainfrom
rewrite-container-parsing
Open

Rewrite container parsing#61
yaito3014 wants to merge 47 commits intomainfrom
rewrite-container-parsing

Conversation

@yaito3014
Copy link
Member

@yaito3014 yaito3014 commented Mar 2, 2026

partially addresses #25
supersedes and closes #50

including:

  • renaming is_substitute to can_hold
  • rewriting parse_into_container with constexpr if
  • fixing move_to with subrange handling

Todo

  • Add tests
  • Fix typo pass_attibute_as_is -> pass_attribute_as_is
  • Remove unused_container and assume_container if possible
  • Rename build_container to default_container
  • Remove the branch fix-swapped-template-argument
  • Remove raw directive

Removal of the raw directive

What raw does

The raw directive wraps an inner parser and produces the iterator range (begin/end pair) of the successfully matched input as its attribute, instead of the semantic value that the inner parser would normally yield.

Use cases

A typical use case is extracting the raw matched substring from the input. For example, while int_ produces an int as its attribute, raw[int_] produces the iterator pair corresponding to the matched portion of the input. This can be useful for retaining the original string representation of parsed content or recording source positions for error reporting.

The problem

Internally, the library needs to determine whether a parser's attribute is compatible with container types (e.g., std::vector) when resolving exposed attributes. With raw in the picture, the attribute type becomes an iterator pair, which means the iterator type must be known to perform this compatibility check accurately.

However, the iterator type depends on the input source and is not available at parser definition time. This fundamentally conflicts with the design goal of determining attribute compatibility statically from the parser definition alone. Supporting raw correctly would require propagating the iterator type as a template parameter throughout the attribute compatibility logic, significantly complicating the library's internals.

Rationale for removal

The use cases for raw are relatively niche, and most of them can be addressed by creating a custom parser class that deals with the actual iterator and sentinel positions directly. Note that _where, which is already deprecated in favor of raw, should also be fully removed as part of this change. Given the disproportionate complexity raw introduces into the type system, its removal is a reasonable trade-off in favor of a cleaner and more consistent internal design.

@yaito3014 yaito3014 added enhancement New feature or request help wanted Extra attention is needed labels Mar 2, 2026
@saki7 saki7 removed their assignment Mar 2, 2026
@saki7
Copy link
Member

saki7 commented Mar 2, 2026

@yaito3014 Reassigning due to non-rule-related tests still failing, please check the build log.

// iris::rvariant<int, double> is "broader" than int
STATIC_CHECK( x4::traits::can_hold_v<iris::rvariant<int, double>, int>);
STATIC_CHECK(!x4::traits::can_hold_v<int, iris::rvariant<int, double>>);
}
Copy link
Member

Choose a reason for hiding this comment

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

TODO: add more tests

@saki7 saki7 removed the help wanted Extra attention is needed label Mar 4, 2026
@saki7
Copy link
Member

saki7 commented Mar 4, 2026

Removed the label "help wanted".

"help wanted" and "good first issue" are special labels that GitHub uses it for advertising the repository issues to potential contributors. When you apply this label, it's recognized by GitHub's recommendation engine to make the issue appear on GitHub's top page feed. Please add this label to a context-free, easy tasks only.

@yaito3014
Copy link
Member Author

supersedes #50

@cppwarningnotifier
Copy link

EnvironmentC++23C++26
x4Clang21Debug✅success✅success
Release✅success✅success
GCC14Debug✅success✅success
Release✅success✅success
MSVC2022Debug✅success✅success
Release✅success✅success
2026Debug✅success✅success
Release✅success✅success

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

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants