Rework reflect Constant API

[nicolasstucki]

Add types for specific constants as in the tasty format specification. This also aligns the API design with the rest of reflection by useing TypeTests (this inconsistency was noticed in #10738 (comment)).

- Constant.Int(x)
+ IntConstant(x)

- Constant.Long(x)
+ LongConstant(x)

...

[liufengyun]

It seems we have too many concepts here. Can we just keep one concept Constant as it's in the compiler?

class Constant(...) {
    def isByteRange: Boolean
    def isShortRange: Boolean
    def isCharRange: Boolean
    def isIntRange: Boolean    
    def isLongRange: Boolean
    def isFloatRange: Boolean
    def isNumeric: Boolean
    def isNonUnitAnyVal: Boolean
    def isAnyVal: Boolean

    def booleanValue: Boolean
    def byteValue: Byte
    def shortValue: Short
    def charValue: Char
    def intValue: Int
    def longValue: Long
    def floatValue: Float
    def doubleValue: Double
}

[nicolasstucki]

That API does not allow you to know what the type of the constant is. It also does not provide concrete constructors.

[nicolasstucki]

Those are all implementation details that are not really in TASTy

[nicolasstucki]

This is the only part of the abstraction we can relly on being stable https://github.com/lampepfl/dotty/blob/master/tasty/src/dotty/tools/tasty/TastyFormat.scala#L134-L146

[nicolasstucki]

It seems we have too many concepts here.

In this PR we do not increase the number of concepts, we just move them to follow the same API design as Trees and other abstraction.

[liufengyun]

This is the only part of the abstraction we can relly on being stable https://github.com/lampepfl/dotty/blob/master/tasty/src/dotty/tools/tasty/TastyFormat.scala#L134-L146

It's indirectly decided by the language spec, which is more stable than TASTY.

[liufengyun]

LGTM

I believe there is room to have simpler and cleaner APIs without introducing so many concepts. But as the usability aspect is subjective, and the constant APIs are not commonly used in meta-programming, thus I think the changes are fine.

[deusaquilus]

I think this is a Much uglier API then before. Compare this:

      term match
        case Literal(StringConstant(v: String)) => Some(v)
        case Literal(IntConstant(v: Int)) => Some(v)
        case Literal(LongConstant(v: Long)) => Some(v)
        case Literal(BooleanConstant(v: Boolean)) => Some(v)
        case Literal(FloatConstant(v: Float)) => Some(v)
        case Literal(DoubleConstant(v: Double)) => Some(v)
        case Literal(ByteConstant(v: Byte)) => Some(v)
        case _ => None

To this:

      term match
        case Literal(Constant.String(v: String)) => Some(v)
        case Literal(Constant.Int(v: Int)) => Some(v)
        case Literal(Constant.Long(v: Long)) => Some(v)
        case Literal(Constant.Boolean(v: Boolean)) => Some(v)
        case Literal(Constant.Float(v: Float)) => Some(v)
        case Literal(Constant.Double(v: Double)) => Some(v)
        case Literal(Constant.Byte(v: Byte)) => Some(v)
        case _ => None

This StringConstant, IntConstant, etc... reminds me of Java's Hadoop's IntWritable, LongWritable, DoubleWritable. That was a nasty way of doing things I was hoping I would not need to work with again.

Can we at least have Constant.String, Constant.Int etc... available as an unapply?

[nicolasstucki]

Actually you just need

 term match
        case Literal(StringConstant(v)) => Some(v)
        case Literal(IntConstant(v)) => Some(v)
        case Literal(LongConstant(v)) => Some(v)
        case Literal(BooleanConstant(v)) => Some(v)
        case Literal(FloatConstant(v)) => Some(v)
        case Literal(DoubleConstant(v)) => Some(v)
        case Literal(ByteConstant(v)) => Some(v)
        case _ => None

[deusaquilus]

That makes sense. Thanks!
I still like the one with dots more 😊

[nicolasstucki]

I also liked it but it made more sense to change it for the sake of consistency with the rest of the API. This will help with doc navigation which is already non-trivial.

[deusaquilus]

Could I somehow wire this up myself? I recall in Scala 2 trying to do implicit class FooExt(fooObject: Foo.type) { ... } would crash the compiler. Is it possible to add extensions methods to an object with Scala 3?