Scala 宏禁止非法对象构造后，抑制非穷尽匹配警告是否可靠

核心结论 #

仅靠当前实现的宏apply拦截非法实例，直接无条件抑制非穷尽匹配警告是完全不可靠的，存在多个可以绕过约束的构造路径，迟早会碰到运行时匹配失败的问题

具体风险点 #

• 没有完全封死所有构造入口
  现在的宏只会拦截调用伴生对象Info.apply的场景，但你定义的Info是公开的case class，自带的公共主构造器可以被任意调用——比如直接写new Info(test1Instance, bInstance)，完全绕开伴生对象的逻辑，宏的校验根本不会触发，之前的不匹配实例依然可以被正常创建，运行时碰到自然会抛MatchError。
• 当前宏的校验逻辑本身不完整
  现在的宏只检查泛型参数T是不是final的具体子类，完全没有校验传入的元数据m和T对应Meta类型的匹配关系。就算把构造器完全封死，只要利用Scala的存在类型擦除、强制类型转换（asInstanceOf）、隐式转换绕路，依然可以构造出t和m不匹配的Info实例，现有宏逻辑根本识别不出这类非法构造。
• 编译器的穷尽检查和你的宏约束是完全脱节的
  编译器做模式匹配穷尽性判断时，只会根据Scala语言本身的类型规则推导合法取值范围，它根本感知不到你加的宏构造限制。不管你是全局关掉警告，还是加注解压掉提示，从编译器视角看Info[_ <: Test]类型的合法取值依然包含警告里列出的所有非法组合，这些组合的存在性从类型系统层面没有被真正消除。

可靠落地的前置条件 #

要让压掉警告的逻辑不会留坑，必须把所有能造出非法实例的路径全部堵死：

• 把Info类的主构造器设为私有，不允许外部直接实例化，强制所有Info对象只能通过伴生对象的方法创建，从根源上堵死绕开校验的路径。
• 完善宏的校验逻辑，除了校验T是具体的Test子类，还要在编译期比对传入的m的实际类型，和当前T对应的Meta类型做严格对应关系校验，从构造源头上杜绝t和m不匹配的实例。
• 当所有构造路径都被封死、从业务规则层面已经不存在非法的Info实例之后，再针对对应的match块加局部的警告抑制，这种操作才是可靠的，不会出现运行时匹配失败的问题。

内容的提问来源于stack exchange，提问作者Some Name