Move 团队交流问题收集
请列举出自己关心的 Move 相关的问题。
基础类型的扩充以及 Math 的增强
能否支持 u256
能否支持判断计算是否溢出的办法
能否支持类似 rust 中的 saturating_sub 和 saturating_add
语法和类型系统
friend可见性的使用有没有可能简化或者增强？比如 address 可见或者跨 address 可见
Struct public field 以及反序列化支持，这样 struct 可作为交易参数
开发工具方面的增强
多版本 bytecode 编译的支持，比如用 v3 的编译器编译出 v2 版本的二进制
unit-test 的初始化
类似 GDB或者LLDB一类的调试工具
复杂项目的工程化，Solidity很难构建复杂系统，Move有没有这方面的考虑
Map 的支持
与泛型结合，存储已知的支持泛型的类型，不需要 signer。
全局排重
是否有可能申明一种带所有权的 Map，将 move_to/move_from/global_borrow 指令通过 Map 的操作表达出来。
在swap和bridge项目开发过程中，使用Move遇到一些问题：
大数计算
背景1：bridge打通以太坊等主流资产跨链到starcoin，以太坊生态里大量项目使用18位的decimal，类型为u256，而move里最大为u128，最大可以表示约39位长度的uint，为了兼容两条公链，需要在bridge里实现以太坊u256的兼容逻辑。
背景2：swap项目中，有对个地方涉及到u128 * u128的乘法，以及大数的除法，为了避免溢出或者丢失精度，额外封装了SafeMath来处理大数运算，但也只能保证部分场景有效。
诉求：不论是Move自有生态的发展诉求，还是从其他生态迁移过来，native u256都是一个很重要的特性，提供大数计算能力。
Mapping
背景：Move的理念是每一份resource都在owner的存储空间，且具备状态计费的能力，这一点比以太坊是很大的一个优势。而Mapping恰恰是违背这个理念的。在bridge项目中，需要在合约里对全局全量交易进行排重，不支持淘汰和过期，暂时的实现思路是链下维护全量交易，链上仅存储存在性proof证明，来实现全量全局排重需求。不过整个方案还是有些复杂，尤其是给到生态内的项目使用，有一定的门槛。
需求：是否有从语言层面，更优雅的对Mapping类场景的解决方案？
String
背景：Move中没有string类型，用vector<u8>来表示字符串。在开发bridge项目中，为了比对和验证两条公链签名和验签的一致性，写了大量测试代码来验证。一个痛点时，当想把Move中生成的签名在Solidity中测试是，只能拷贝bytes，非常不直观。相信在多个生态迁移时，这个问题会普遍遇到，虽然不影响功能，但确实是一个很麻烦的点。
需求：能否考虑对string的原生支持。a
如何推广 Move
区块链圈子里的很多人认为 Solidity 和 Evm 已经占据了主导地位，类似于当年的 javascript，其他的竞争者已经没有机会了。我们需要一起努力想办法推广 Move，构建 Move 生态，改变这种看法。