Remove scala.quoted.{Const, Consts}

[nicolasstucki]

This extractor is redundant and needs to be removed before 3.0.0-RC1 as we do not want to break the API after that.

All use case of Const are covered by simpler calls to .unlift/.unliftOrError or by the more general Unlifted extractor.

[nicolasstucki]

The only valid objection so far is that the name looks better in some situations. That can be worked around using renames in imports or creating a simple Const definition outside that library that reuses the logic of Unlifted.

[liufengyun]

#10572 (comment)

Const.unapply guarantees that no evaluation happens in the unlifting, while there is no such guarantee in using .unlift or Unlifted. Meanwhile, Const is more specific and precise when users only want to match literals in programs.

Users should use .unlift most of the time. However, it is not a replacement for Const.unapply, as
the semantics of .unlift depends on the imported Unliftable instance --- it does not provide the semantics intended by Const.unapply.

[nicolasstucki]

Const.unapply guarantees that no evaluation happens in the unlifting, while there is no such guarantee in using .unlift or Unlifted. Meanwhile, Const is more specific and precise when users only want to match literals in programs.

Not true, both guarantee the same amount of evaluation for primitive types. Their implementation is the same code.

However, it is not a replacement for Const.unapply, as the semantics of .unlift depends on the imported Unliftable instance --- it does not provide the semantics intended by Const.unapply.

It does as that is the spec. It would not only if you implement a custom Unliftable that does not follow the spec.

[nicolasstucki]

The code for Const and Consts can already be found in scala.quoted.util (unpublished).