问题标签 [scala-3]

我对 Gradle 和 Dotty 都很陌生（对 Scala 整体来说还是比较新的）。我能够像这样使用 Gradle 创建一个 Scala 项目：

而且我知道 Dotty 可以与 SBT 一起使用。但是有没有办法将 Dotty 与 Gradle 连接起来（还）？

在查看 Dotty 的 (Scala 3.0)运算符规则时，我注意到以下@alpha注释示例：

此示例旨在说明如何显式设置方法在具有 java 不允许的字符时将被编译的名称，但它似乎也表明了一种定义静态中缀方法的新方法，据我所知到这一步是不可能的。

当我尝试：

我的编译器告诉我迷路。

这是一个新功能吗？我希望如此，因为我希望能够编写静态中缀函数而不求助于隐式转换。

如果这是 3.0 的新功能，为什么在操作员规则部分（或其他任何地方）没有提到它？

类型推断的哪些变化为Dotty带来了更好的类型推断？Option#fold例如

而在 Scala 2.13.3 中出现错误

这似乎与多个参数列表有关，例如Option#fold

在 Scala 2 中的工作如下

这种行为或推断在应用程序类型检查的方式中运行得非常深入，并且它依赖于 foldLeft 等 API，它允许通过考虑第一个参数列表来累积约束，从而允许您省略第二个参数列表中的类型。

但是在上面的示例中它适得其反，因为应用于第二个参数列表的“累积约束”是Left[String,Nothing].

我试图使用匹配类型在 Dotty 中实现SKI 组合器演算。

SKI 组合微积分的简要说明：

• S, K, 和I是项
• (xy)is an term if xand yare terms and is like 函数应用
• (((Sx)y)z)(same as Sxyz) 返回xz(yz)(same as (xz)(yz))
• ((Kx)y)（相同Kxy）返回x
• (Ix)返回x

以下是我使用R的（尽可能减少术语）。一个术语(xy)被写成一个元组(x,y), 和S, K, 和I是特征。

但是，以下 2 行无法编译（出于相同的原因）（Scastie）：

该错误说它需要(K,K)但找到R[((I, K), (I, K))]。我希望它首先看到 S 并将其变成(IK)(IK)，或者R[((I,K),(I,K))]，之后它应该匹配第一个的评估(I, K)并看到它是K，这与(I, K)使其返回R[(R[(I,K)], R[(I,K)])]，它成为R[(K,K)]，它成为正义(K,K)。

然而，它并没有超越R[((I,K),(I,K))]。显然，如果它是嵌套的，它不会减少术语。这很奇怪，因为我尝试了相同的方法，但使用了实际的运行时函数，而且它似乎工作正常（Scastie）。

正如预期的那样，来自println(r((((S, I), I), K)))的输出。(K,K)

有趣的是，删除它的规则K让它可以编译，但它不能识别(K, K)和R[(K, K)]作为同一类型。也许这就是导致问题的原因？（斯卡斯蒂）

扩大联合类型已在此处讨论，但我似乎无法找到以下案例的答案

让我们从以下内容开始

这个异构列表的推断List[Any]就像在 Scala 2 中一样

然而以下

被推断为List[scala.collection.immutable.AbstractSeq[Int | String]]

这是相当令人困惑的行为。为什么在一种情况下推断出两种不相交类型的 LUB，Any而在另一种情况下推断出联合类型？

如果这只是一个设计决策，是否有任何应该注意的情况？

我想使用Scala 3并使用一些现有的库。该示例适用于 Scala 2.13。

编译时出现此异常：

这是我的build.sbt

更新 好的，它适用于2.12，使用2.13我收到以下错误：

在Dotty中给出以下内容：

我想“简化”BaseCreate这样我可以Create像这样实现：

我试过了：

但是编译器抱怨：

这对我来说没有意义。什么是正确的语法，如果有的话？

使用此代码链接到 scastie

PS：我不想再向BaseCreate. 尤其是F因为这意味着该类Domain.Create将需要final case class Create[F[_]]完全不是预期的解决方案。

我有以下情况：

这给了我以下编译异常：

Scala 3中扩展方法的命名是否有限制？

请参阅Scastie上的示例

I went through the documentation and found a couple of ways how to define ad-hoc behavior for type class instances. Here's the original example:

The funny thing is we could define a bunch of ordinary infix methods alongside with extensions. The user expected behavior should be the same (despite the implementation differences).

Here's the example which illustrates that:

Since both constructs are doing the same thing (in different ways), it rises a question: which way is the most idiomatic? If both, in which situations each works best?

Thanks!

我害怕阅读 Scala 3 会带来什么，特别注意复合类型的变化。它们总是有点像黑客，所以干净、真正的交叉口类型肯定是一种改进。我找不到关于复合类型的实际细化部分发生了什么的任何信息。在我当前的项目中，我严重依赖于强交织类型，以试图让每个返回值尽可能窄。因此，例如，拥有

甚至还有可能吗？如何用新的语义来实现这个目标？据我了解，抽象类型的改进几乎肯定是不允许的，因此在类型层次结构的根中很难有一个“自我类型”声明：

在一个有点相关的注释中，我正在研究结构类型。我必须说我喜欢我们如何使用静态声明来动态选择/实现成员。抽象类是否可能？我可以写类似的东西：

编辑：我找到了相关的文档，看起来匿名Selectable实例不受匿名类的类型是其扩展类型的交集的规则的约束——很好。