问题标签 [implicit]

更新！

请参阅下面我对 C# 规范的一部分的剖析；我想我一定遗漏了一些东西，因为在我看来，我在这个问题中描述的行为实际上违反了规范。

更新2！

好的，经过进一步思考，并根据一些评论，我想我现在明白发生了什么。规范中的“源类型”一词指的是转换自的类型——即，Type2在我下面的示例中——这仅仅意味着编译器能够将候选者缩小到定义的两个运算符（因为Type2源类型是对彼此而言）。但是，它不能进一步缩小选择范围。所以规范中的关键词（因为它适用于这个问题）是“源类型”，我之前误解（我认为）它的意思是“声明类型”。

原始问题

假设我定义了这些类型：

然后说我这样做：

显然这是模棱两可的，因为不清楚implicit应该使用哪个运算符。我的问题是——因为我看不到任何解决这种歧义的方法（它不像我可以执行一些显式转换来澄清我想要的版本），但是上面的类定义确实编译——为什么编译器允许那些匹配的implicit运算符？

解剖

好的，我将通过 Hans Passant 引用的 C# 规范的摘录来尝试理解这一点。

找到将考虑用户定义的转换运算符的类型集 D。该集合由 S（如果 S 是类或结构）、S 的基类（如果 S 是类）和 T（如果 T 是类或结构）组成。

我们正在从 Type2( S )转换为 Type1( T )。因此，这里的D似乎包括示例中的所有三种类型：（Type0因为它是S的基类）、Type1（T）和Type2（S）。

找到一组适用的用户定义的转换运算符 U。该集合由 D 中的类或结构声明的用户定义的隐式转换运算符组成，它们从包含 S 的类型转换为由 T 包含的类型。如果 U 为空, 转换未定义并发生编译时错误。

好的，我们有两个满足这些条件的运算符。in 声明的版本Type1符合要求，因为Type1它在D中，并且它从Type2（显然包含S）转换为Type1（显然包含在T中）。出于完全相同的原因，in 中的版本Type2 也符合要求。所以U包括这两个运算符。

最后，关于在U中查找运算符的最具体的“源类型” SX：

如果 U 中的任何运算符从 S 转换，则 SX 是 S。

现在，U中的两个运算符都从S转换- 所以这告诉我SX是S。

这不是意味着Type2应该使用该版本吗？

可是等等！我很困惑！

难道我不能只定义Type1' 运算符的版本，在这种情况下，唯一剩下的候选者将是Type1' 版本，但根据规范SX将是Type2？这似乎是一种可能的情况，其中规范要求一些不可能的事情（即，Type2应该使用中声明的转换，而实际上它不存在）。

显示的代码会出错，因为“Base”的默认构造函数（隐式）被抑制。确实，标准是 12.1 美元"If there is no user-declared constructor for class X, a default constructor is implicitly declared."

有三件事：

a）标准是否在任何地方说明如果用户声明的构造函数存在于类中，则默认构造函数（隐式）被抑制。基本上上面的措辞是负面的，还是再次暗示:)？

b) 为什么会这样？

c) 为什么相同的规则不适用于默认析构函数？

保留的问题 - 请参阅底部的编辑
我正在开发一个小型功能库，主要是通过隐藏基本的圈复杂性来提供一些可读性。调用提供者Select<T>（带有一个名为 的辅助工厂Select），用法类似于

并且库会处理短路等问题。我还添加了一个隐式转换 from Select<T>to T，所以我可以写

我真正想做的是在没有赋值的情况下隐式转换为 T ：

但是，指定的语法不起作用 - 我必须将其分配给变量，或显式转换它。有没有办法获得隐式转换内联？

编辑

我想做的是：

为什么编译器抱怨：

错误：找不到参数映射的隐式值：scala.collection.mutable.Map[String,T] names.foreach(createEntity[T])

?

我有一个包含许多项目的解决方案，这些项目都使用相同的根命名空间。没有代码文件明确命名命名空间。所以可以说根命名空间是ExampleRootNamespace.

现在，当我想将显式命名的命名空间添加到我正在处理的代码文件之一时，就会出现问题。我希望能够将此代码与程序集的其余部分隔离，以便能够针对它运行 FxCop。所以我Namespace Interfaces.CSV在代码文件中添加了类似的东西。

这会导致引用此程序集的任何代码都需要说Imports ExampleRootNamespace.Interfaces.CSV. 到现在为止还挺好。我什至可以针对程序集运行 FxCop。现在的问题是，在其他程序集中我不能再说什么了，比如：

Visual Studio 现在要求我将命名空间重命名为：

有数百个与此相关的错误。所以我的问题是：

1）为什么第一次在根目录下命名命名空间会导致程序出现问题？

2）在不重命名的情况下是否有解决此问题的方法？

我还想补充一点，ExampleRootNamespace.Interfaces.CSV我没有在代码库的任何地方引用它。我目前只是从一个单元测试项目中引用它。所以我不明白为什么添加这个命名空间会导致问题。

考虑以下代码：

这可行，但我需要将 Some(42) 键入为 Option[Int]，否则将无法解析隐式对象 OptionBar（因为需要使用 Bar[Some]）。有没有办法避免显式键入，以便即使我用 Some 或 None 提供测试，我也会在测试中获得隐式 OptionBar 对象？

[澄清]

• 我在这里使用了 Option 作为示例，如果我有Bar一个抽象类等，它也应该可以工作。
• 当其他不相关的条在范围内时，该解决方案也应该起作用，例如implicit object listBar extends Bar[list]

[更新]

似乎使 Bar 的参数逆变可以解决问题：

但当然这是对 Bar 可能性的严重限制，所以我仍然希望有更好的答案。

如果我有这两个构造函数MyClass：

和一个重载（非成员）operator+：

这使我能够编写如下代码：

我猜它通过定义的构造函数使用隐式转换，对吗？

有什么办法可以通过构造函数采用 2 个参数来进行这种隐式转换？代码看起来像这样：

?

或者也许只是从 {9, 4} 到一个MyClass对象的显式转换？

我想将一些来自不同类型层次结构的对象存储到List[Any]或类似的容器中，但稍后对它们执行隐式转换以执行类型类之类的操作。这是一个例子：

上面的代码抛出如下错误：

如果你取消注释AnyPrices，你会得到List(0,0)，但这不是我所期望的。我是否必须将清单存储到列表中才能正常工作？

此外，List(Prius(2010)) map { implicitPrice(_) }也不起作用，因为它想要Price[Prius]并且Price[Car]不够好。有没有办法让它更灵活？

我想定义一个适用于 type 的所有子类型的通用隐式转换器T。例如：

上面的代码抛出一个错误：

我究竟做错了什么？

更新：

正如@extempore指出的那样，错误在于我混淆了隐式转换（视图边界）和上下文边界（两者都使用隐式参数）。我的通用隐式转换器没有任何问题。问题是add使用上下文边界而不是视图。所以我们可以修复如下：

Price[A]@extempore 在他的代码中展示的一件有趣的事情是，如果是逆变的，我们实际上并不需要通用转换器。基本上，我可以Price[Car]代表 工作Price[Prius]，这正是我想要的。所以替代的上下文绑定版本是：

相关：

• [scala] 通用隐式转换器？

在 Scala 中，重载和隐式参数解析的相互作用似乎使以下代码无法使用。

这里的目标是让 a.as[B] 执行类型安全转换，而不管 Bijection[A,B] 或 Bijection[B,A] 在隐式范围内是否可用。

这不起作用的原因是隐式解析似乎发生在编译器中的重载消歧之后，并且由于 'as' 的两个实现具有相同的结果类型，编译器甚至没有尝试找出适当的隐式是否在可以执行转换的范围内。简而言之，在重载消歧中不使用隐式解析。

我想让'as'重载的原因是为了避免这个库的用户需要在调用站点对双射的“方向”进行编码；显然可以这样实现 Biject：

但这真的很不吸引人，因为它本质上使皮条客变得多余；不妨明确地通过双射，但当然你失去了使所使用的双射根据范围而变化的能力。

这个问题有什么好的解决办法吗？