@dobelee 参考原文：**需要至少 Windows 11 23H2 ，目前还没有发布正式版本，不过可以考虑加入 Insider 的 Release Preview 或者 Beta 通道。**
你可以加入 Windows Insider 进入 Release Preview 或者 Beta 通道，然后更新系统，然后就可以了。

[win11]( https://imgur.com/a/r4ynIPF)

win11 无法复现这个问题，考虑更新到最新版本？

@Shosuke 同步读取本地 chrome 数据那是因为用了 chromium 内核，任何用了 chromium 内核的浏览器都能够相互共享本地的数据，包括密码。

@aabbcc112233 冷知识：Chrome 117 也加入了购物推荐和跟踪。

@bv 可以点进去然后看他下一篇博文就是 https://chai2010.cn/post/golang/go-safe-interface/
这其实就是经典的语言设计失误才导致的问题，在没有从类型外部实现接口这种东西出现之前用鸭子类型倒是还能理解，但是作为一个 21 世纪诞生的语言就是纯粹的开倒车，只会带来一大堆的接口被意外实现的问题。
你可以看他前篇文章刚刚在“1.12 实现接口不需要明确声明”反驳了这个问题的存在，后篇文章立马就写这个问题的 workaround ，这不是自打脸了么。

golang 难道不是从最开始的自我定位就是最适合拉屎的语言？都用 golang 了就不需要管代码到底怎么设计和抽象了，怎么暴力怎么来。
不过也正是因为这样很多一开始根本不会编程的人看到 golang 都能立马上手，甚至比 python 还好上手。他们不需要在入门的时候理解各种语法、概念和工作原理，只要简单理解一下基础类型和控制语句什么的然后照着 api 文档抄就能写出像模像样的东西，算是大力推进了开发者群体下沉吧。
打个比方就是，虽然使用从句能让英语表达更加丰富、信息密度更高、语素重复更少，但不是每个英语学习者都会；而所有英语学习者只要经历了最初的学习就能使用简单句来进行语言表达。

@geelaw 其实有一个非常简单的方法用来判断一个特性能否不需要修改 IL 来实现。只要一个特性涉及到跨 ABI ，那就不能只在上层语言层面做实现。

@geelaw 提前建立出来也是有最开始提到的问题的，建立出来的类型一定是在某个程序集中的，于是 A.Integer42 和 B.Integer42 不是同一个 42 ，于是会导致各种类型上的问题。而原生的 const generics 则不存在这个问题。
到头来原本想通过语法糖的方式简化实现，结果反而将一大堆东西复杂化了，最后结论是这个东西一定不能做成语法糖。

@geelaw 不是的，对于后者，新的值只需要提前提供 instantiation 的参数就能让编译器提前生成代码，比如 42 ，你可以通过 rd.xml 之类的方法来指定需要的泛型参数，就能使得从任何地方调用 `G2<42>` 成功，例如：
```xml
<Type Name="G2`1">
<GenericArgument Value="42" Type="System.Int32" />
</Type>
```
而前者的话无法通过 rd.xml 来指定，因为在编译期对运行时创建的新类型一无所知，通过 rd.xml 只能指定类型的名字，而无法编写类型的实现。

@geelaw 弄成语法糖显然是不行的，因为编译器生成的类型只会在它所在的项目编译出来的程序集里存在，假设你在 A 项目里用了个 `Foo<42>`，而 B 项目里用了个 `Bar<42>`，你会发现尽管 42 在两侧值都是一样的，但实际上不是一个类型（前者是 `struct A.IntConstant42`，后者是 `struct B.IntConstant42`），于是相互是不兼容的，于是无法相互传递。而且由于你在 A 处压根不知道 B 处的 `IntConstant42` 类型，隐式转换的代码也是无法生成的（隐式转换操作符不支持从接口转换，也不支持泛型）。
另外就是，这么一来，如果你在运行时通过反射调用包含 const generics 的 API ，那你就不得不现场 emit IL 产生一个新的类型，这和 nativeaot 就是完全不兼容的，通过使用 rd.xml 也无法解决。

msstore 上测试的系统是没有带任何环境的，就是一个全新安装的 Windows ，你可能得找台没有装过环境的系统测试能不能正常安装运行。

@hez2010 况且，explorer 从来都没有 API 让你修改成旧风格的开始菜单，不管是公开的还是私有的 API 都没有，要做这件事只能劫持 explorer 的内存地址。

做个简单的不准确的解释的话就是，假设你点击开始菜单的时候 explorer.exe 会执行一个内部的 `OpenStartMenu` 函数打开开始菜单，现在 Explorer Patcher 想要把开始菜单换成他们自己做的旧风格的开始菜单，那怎么做呢？

于是 Explorer Patcher 的开发者通过逆向工具找到这个内部的 `OpenStartMenu` 函数的地址，比如说是这个地址是 `A`，然后他们写一个 dll 在 explorer 启动的时候注入到 explorer 进程里，这个 dll 被 explorer 成功加载之后就会给地址 `A` 插入一条跳转指令使得只要代码执行到 `A` 这里就会跳转到他们自己做的打开开始菜单的函数地址上。这样当你点击开始菜单的时候，explorer 想要执行 `OpenStartMenu` 函数但是被 patcher 的 dll 篡改掉了，于是执行了 patcher 自己的函数，实现了打开旧风格的开始菜单。

那现在 explorer 因为一些原因，比如修复安全漏洞等等，加了一些代码恰好使得重新编译之后 `OpenStartMenu` 函数的地址变了，这可并没有修改任何的 API ，结果 patcher 仍然是按照以前的 `A` 地址进行篡改，这样必然会导致别的什么东西被改掉了，于是使得正常的 explorer 崩溃了。

这难道是 explorer 自己的问题？

@nothingistrue 然而根本就不是「最低安装目标级别提高到 23 」这种变更。

你要知道各种 explorer patcher 插件的原理：注入他们自己的 dll 到 explorer.exe 进程中，替换掉某个内存地址上的函数指针指向他们插件自己的函数来实现自动自定义逻辑，然后这个内存地址还是通过各种逆向工具 dump 出来的。

explorer 自己往自己某个私有类型里加了个私有函数自己用，结果因为这样使得你的插件应该 hack 的地址偏移变了导致崩溃，这总不能是 explorer 的问题吧？

explorer 的 api 从来都是 undocumeted 的，自然也就不存在任何的兼容性保证。

如果你的 jar 是 target 到 Java8 的话可以直接通过 ikvm 来调用。
使用方法也很简单，c# 项目里直接引用 jar 包就能直接用了。
https://github.com/ikvmnet/ikvm

@thinkershare 算术约束我已经另一个分支实现了 prototype ，只不过最终实现方案还有待讨论。

@nulIptr 我倾向于叫他 const generics ，因为和 rust 的 const generics 比较像。
另外，实现 typescript 那种 literal types 我们之前也考虑过，但是拒绝了，因为无法忍受每一个字面量都需要在运行时带上一个 TypeDesc 的开销，并且单纯的 literal types 除了能做体操之外意义不是很大，所以我们倾向于只做类似 C++ 和 Rust 那样的模板值特化。想要 literal types 的话没必要做在 runtime 层面，停留在 C# 编译器层面就行了。
这个特性目前还有一部分内容在设计中，例如算术约束和依赖类型等，我也是最近才刚刚完成了 CoreCLR 部分的实现。所以 .net 9 能不能有我不是很清楚，只是说最早能在 .net 9 实装。