Config API enhancements needed for safe recursive config traversal

[amorphobia]

概述

SchemaOpen / ConfigOpen 丢弃了 native bool 返回值，而 GetList / GetMap 将三种不同状态（路径不存在、类型不匹配、空容器）坍缩为相同的结果。这些缺口使得下游调用方（如 RimeSharp.PowerShell 或其他绑定使用者）无法安全实现 Get-RimeConfigSnapshot——即递归复制配置树到托管内存、并能可靠区分错误状态与合法空数据的 cmdlet。

当前行为

// Rime.cs — SchemaOpen 忽略 native 返回值
public RimeConfig SchemaOpen(string schemaId)
{
    var config = new RimeConfig();
    _api.SchemaOpen(schemaId, ref config);   // bool 被丢弃
    return config;                            // 调用者无法得知是否有效
}

// RimeConfig.cs — GetList 将未找到、类型错误、空容器坍缩为同一结果
public T[] GetList<T>(string key, Func<RimeConfig, string, T?> getFunc)
{
    ...
    if (!api.ConfigBeginList(ref iter, ref this, key))
        return [];    // 三种不同情形 → 相同的空数组
    ...
}

GetMap 同理。

建议改动

1. 让 config 打开函数可失败

使用可空返回值

public RimeConfig? SchemaOpen(string schemaId)
{
    var config = new RimeConfig();
    return _api.SchemaOpen(schemaId, ref config) ? config : null;
}

ConfigOpen 和 UserConfigOpen 同理。

2. 让节点类型可检测

暴露 ConfigBeginList / ConfigBeginMap 的返回值，让调用方能无歧义地探明某路径的节点类型。

方式一——在 RimeConfig 上新增方法：

public bool IsList(string key) => Rime.Instance().ConfigBeginList(key, ref this);
public bool IsMap(string key) => Rime.Instance().ConfigBeginMap(key, ref this);

方式二——单一查询方法：

public enum RimeConfigNodeType { NotFound, Scalar, List, Map }
public RimeConfigNodeType GetNodeType(string key);

影响范围

• RimeSharp.PowerShell 可以安全地实现 Get-RimeConfigSnapshot
• 当前 SchemaOpen/ConfigOpen 的现有调用方拿到一个有效性不可知的 RimeConfig——这是任何调用这些方法并使用结果的代码路径中的潜在 bug
• 向后兼容：现有调用方可通过简单机械迁移更新（SchemaOpen(id) → SchemaOpen(id, out var config) 或 SchemaOpen(id) ?? fallback）

[WhiredPlanck]

1. 关于 SchemaOpen 和 ConfigOpen 所使用 C API 可能返回 false 表示打开失败的问题，我有两个想法：一是如同你的建议，让这两个 C# 返回可空的 RimeConfig，开发者可使用判空检测有效性；二是仍然返回非空的 RimeConfig，但在 C API 返回 false 时丢出错误，开发者通过 try-catch 来判明有效性。不知道哪个更适合。
2. Rime 的 Config get 类型 API 其实期待开发者知道预定路径的节点类型。除非你想自己用这些 API 来将配置先全部读取为一个节点，然后逐层获取节点值。RimeConfig 目标是提供一个高级封装，或者说是利用 Rime 提供的 C API 还原出 Rime 内部的高级 Config C++ 类，它本身就代表了整个配置文件的数据结构。至于这个封装将错误情况坍缩的说法，我个人认为这是 AI 将问题泛化了 —— 原生 C API 也只是返回了布尔值，仅凭这个是没有办法在端末知道它是类型错误、没找到还是预订路径就是空容器的。当然，我承认这个封装不够完美，还需要进一步设计。

[amorphobia]

1. 实际测试发现，不存在的 schema ID 可以拿到有效的空 config, 所以 librime 返回 false 的话应该是更严重的问题，从这个角度来说，抛异常有一定合理性，我建议抛异常，如果实在有无异常 workflow 的需求，可以加一组 TryOpen 的方法（现在不需要）。
2. 第二个问题，“知道预定路径的节点类型”从前端开发者的角度来说可能是对的；不过有一类开发者也就是 Rime 辅助工具开发，可能并不能预知，他们需要处理各个方案的配置或者各个前端的适配。不过我认为可以等到实际有这类开发者的需求再说。

Thanks a lot!

[WhiredPlanck]

1. 实际测试发现，不存在的 schema ID 可以拿到有效的空 config, 所以 librime 返回 false 的话应该是更严重的问题，从这个角度来说，抛异常有一定合理性，我建议抛异常，如果实在有无异常 workflow 的需求，可以加一组 TryOpen 的方法（现在不需要）。

   2. 第二个问题，“知道预定路径的节点类型”从前端开发者的角度来说可能是对的；不过有一类开发者也就是 Rime 辅助工具开发，可能并不能预知，他们需要处理各个方案的配置或者各个前端的适配。不过我认为可以等到实际有这类开发者的需求再说。

Thanks a lot!

1. 我重温了下 Rime 的代码，其实这两个打开配置的方式 C API 返回 false 的概率极低，因为 librime 给它们的实现逻辑是只要成功分配指针就返回 true，一般除非系统剩余内存不足，无法分配新的指针才返回 false，但这个条件很苛刻。打开不存在的配置/方案只会使得内部的根容器是空的。
2. 这类工具的开发，从已存在的项目分析和我个人角度看，更鼓励开发者用编程语言下配套的解析库去读写（比如 C++ 就用 yaml-cpp，C# 就用 YamlDotNet）。无论再怎么对 Rime 封装，肯定是没有这些库好使的。

[amorphobia]

C API 返回 false 的概率极低

嗯嗯，所以结论是保持现状吗？

鼓励开发者用编程语言下配套的解析库去读写

明白，那么前提就不存在了

[WhiredPlanck]

嗯嗯，所以结论是保持现状吗？

我感觉不是很急，可加可不加。