Define error-policy for wildcard no-match #38

New issue

Closed

opened 2026-07-12 15:28:43 +00:00 by UserCurt · 1 comment

UserCurt commented

2026-07-12 15:28:43 +00:00

(Migrated from codeberg.org)

The expected behavior is unclear when a data-derived matcher such as DotGlob matches no members with MissingPolicy="error".

On the one hand, the wildcard correctly returns zero matches, and this could be considered successful and expected.

On the other hand, the user may have expected the wildcard to match something, and would expect an error otherwise (e.g., if they had a type). It could be surprising for set and remove in particular to be a no-op because a wildcard did not match any fields. This is complicated by the fact that one branch may no matches while other branches have matches. Users may also have different expectations whether the DotGlob is a terminal operator or not.

Examples

Terminal matcher

data = struct();
mpath.resolve(data, "/*", MissingPolicy="error")
mpath.get(data, "/*", MissingPolicy="error")

The wildcard is reached successfully but matches no members. This could be considered a successful empty query rather than an error.

Matcher before a required suffix

data = struct(Z=struct());
mpath.resolve(data, "/Z/*/B", MissingPolicy="error")
mpath.remove(data, "/Z/*/B", MissingPolicy="error")

/Z exists, but * produces no branches on which /B can be traversed. This may warrant an error because the requested descendant target cannot be reached.

Matcher after an earlier empty matcher

data = struct();
mpath.resolve(data, "/*/*", MissingPolicy="error")

The first wildcard is reached and matches nothing. The second wildcard is never reached. This differs from a wildcard that is reached beneath an existing parent but finds no candidates.

The expected behavior is unclear when a data-derived matcher such as `DotGlob` matches no members with `MissingPolicy="error"`. On the one hand, the wildcard correctly returns zero matches, and this could be considered successful and expected. On the other hand, the user may have expected the wildcard to match something, and would expect an error otherwise (e.g., if they had a type). It could be surprising for `set` and `remove` in particular to be a no-op because a wildcard did not match any fields. This is complicated by the fact that one branch may no matches while other branches have matches. Users may also have different expectations whether the `DotGlob` is a terminal operator or not. ## Examples ### Terminal matcher ```matlab data = struct(); mpath.resolve(data, "/*", MissingPolicy="error") mpath.get(data, "/*", MissingPolicy="error") ``` The wildcard is reached successfully but matches no members. This could be considered a successful empty query rather than an error. ### Matcher before a required suffix ```matlab data = struct(Z=struct()); mpath.resolve(data, "/Z/*/B", MissingPolicy="error") mpath.remove(data, "/Z/*/B", MissingPolicy="error") ``` `/Z` exists, but `*` produces no branches on which `/B` can be traversed. This may warrant an error because the requested descendant target cannot be reached. ### Matcher after an earlier empty matcher ```matlab data = struct(); mpath.resolve(data, "/*/*", MissingPolicy="error") ``` The first wildcard is reached and matches nothing. The second wildcard is never reached. This differs from a wildcard that is reached beneath an existing parent but finds no candidates.

UserCurt commented

2026-07-19 13:48:52 +00:00

(Migrated from codeberg.org)

Fixed in b541c6f.

Fixed in `b541c6f`.