feat: support type infer for class memeber

[HerrCai0907]

It introduce a new internal mechanism in resolver to infer the expression type without Flow. Just like decltype() in C++ to support more flexible class definition.

[CountBleck]

Is there any existing code that can be used instead of this, such as (perhaps) whatever code is responsible for let​/const​? Adding a new AST node just for this, and then creating a type from it based off of the NodeKind​ of the expression, makes me a bit uncomfortable, especially since no other type-related AST node contains arbitrary expressions within it (aside from IdentifierExpression​s). Ultimately, it's your call to make, but I'm wondering if there's a better solution?

[HerrCai0907]

Adding a new AST node just for this, and then creating a type from it based off of the NodeKind​ of the expression

We definitely need a node like CompiledExpression in type side to support type infer (not only for this PR, it is only the first application of this kind of node) which has syntax that user does not give the type name but compiler can infer this type.

We have 2 solutions. one is InferredType in this PR, the other is a TypeNode which contains Type directly. Which do you think is better.

I think InferredType is better than the other solution because it is more powerful which can also support generic also. At most of time, missed type should be inferred from a expression, and expression is also AST node, it can keep the compiler layers are not coupled to each other.

[HerrCai0907]

@CountBleck WDYT?

[CountBleck]

I think I've expressed my dislike for CompiledExpression before. It's most likely better to avoid that sort of thing if possible.

…

On Thursday, October 31st, 2024 at 9:20 AM, Congcong Cai ***@***.***> wrote: ***@***.***(https://github.com/CountBleck) WDYT? — Reply to this email directly, [view it on GitHub](#2880 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AS434PFYZK2TGZSDMEJV6UDZ6JKENAVCNFSM6AAAAABQW646BKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJQGI4TCOBRGY). You are receiving this because you were mentioned.Message ID: ***@***.***>

[HerrCai0907]

I agree with you. Then the question is should we follow the current design and patch the AST / Resolver / Compiler to do type inferring or we design a new mechanism and introduce new process during compilation. It may introduce a huge change for Class and Function elements.