`api.json` 的改进

这是对`api.json'的修改列表 我在整理Zig装订时编的 我把它们分为两类:**"改进"用于直接修正,"建议"**用于更大的改变,我想得到反馈. 并且,我先发制人地自愿做这个议题中接受的所有工作.

□ 改进

• Json 格式文档
• Json 格式和 API 版本
• 在任何模块之前包括格式版本和API(按此顺序)。 包括API版本帮助消费者验证内容,并明确处理更古老或更新的版本.
• 向json格式提供一种版本,帮助将生成器绑定,理由与上述相同。 值得现在做这个 未来防守而不是迟到。
• 简单'字段改为doc'字段,以保持一致性。
• [ ]取出未命名的铝,取而代之的是 " 压缩 " 型
• 添加缺失的 “ OC UNICODE RANGE” 值
• 这些内容可以与`OC UI THEM's相同的方式添加。
• 添加缺失的"oc hour" API
• 没有这个API,一些orca样本(如时钟)不可能正确移植.
• 添加缺失的“ oc 窗口” API
• " oc window " 类型名称在API中注明,但未申报。
• 创建 “ oc mat2x3 oc mat2x3 scale( f32 x, f32 y) ”
• 这个甚至不在CPI里 真正应该包括进去是有用的.
• [ 为 UI API 添加文档

□提议

• #117
• 和他们的"父母"合并
• 例如,将“oc file perm”转换为“enum”类型并去掉“oc file perm enum”。 这简化了API表面,同时仍然允许消费者在需要时进行分拆. 它还会防止从"家长"整数类型中偏转的enum的后置整数,例如"oc file perm"(尽管无论这个建议如何,这个问题都可以解决).
• 区分比特旗型与普通型型
• 消费者可以使用更合适的原始方式使用旗子,而不定义每个类型名称的覆盖。 例如,Zig捆绑生成器会自动生成被打包的支架.
• [ 记录单个 IO API 函数可引发哪些错误
• 记录错误应该是每个平台可能出现的错误的超组。
• 这将使消费者能够自信地处理所有可能出现的出错案例。 Zig绑定器会用它来创建出错集,增加额外的类型安全.

其余的是对模块及其内容的组织改变。 它们比较自然 但海事组织觉得更自然 我不指望他们会破坏任何人的密码

• 将Utity模块移走,把孩子移入根中
• QQUtity是一个不好的名字,因为它是模糊和冗余的(API中的所有代码都有效用,否则就不会包括). 这已经反映在函数名中,因为没有一个函数名有oc util '的前缀。 名称"实用"通常也意味着内容是主API的小型助手,然而它包含了一半的API . . . . . . .