Proposal TypeOf Many.

[AdamSpeight2008]

Initial work on the proposal TypeOf Many.
Edit See Issue / Proposal

[AdamSpeight2008]

@AnthonyDGreen
I am currently stuck on how to lower TypeOf obj Is {T0,T1} into
(TypeOf obj Is T0) OrElse (TypeOf obj Is T1)

[xieguigang]

Using Linq Extension for lower it as (TypeOf obj Is T0) OrElse (TypeOf obj Is T1):

For OrElse

If {GetType(T0), GetType(T1)}.Any(Function(t) t Is obj.GetType()) Then
End If

For AndAlso

If {GetType(T0), GetType(T1)}.All(Function(t) t Is obj.GetType()) Then
End If

[AdamSpeight2008]

@xieguigang I don't think using LINQ would be the best target for the lowering, as isn't a direct translation of the intended syntactic sugar.

[bandleader]

1. @xieguigang @AdamSpeight2008 Re: the LINQ solution: you also don't want to use GetType(T0) Is obj.GetType() because that doesn't work for derived types; i.e. TypeOf TextBox Is Control should and does return True, so we should match that behavior.

2. I didn't see the issue/discussion for this proposal, so I'll comment here -- now that pattern matching is a thing under discussion (and has already landed in C#), doesn't it makes sense to do this as part of that? Since both "type checking" (including type guards a la TypeScript) and "multiple options (OR)" are things planned for that.

[AdamSpeight2008]

@bandleader I'll dig out the issue / proposal and update the first post.
Just letting you know I'm not affiliated with Microsoft. I am an external contributor.

Noted, It also not a good implementation to use for this feature proposal. I think there is too much "machinery" involved. The proposal should generate the same code to start with, plus it gives us the option to use different approach for larger number of types to match against. eg Embedded dictionary lookup, like what is used for same Case Selects

As for as I can ascertain pattern-matching may not be part of the road map. Though there ideas / proposals to extend the capabilities of Select and Is which could solve most of the patterns.

This proposal was targeting a very specific use case, simplifying multiple types checks, that follow the pattern
(TypeOf obj Is T0) OrElse (TypeOf obj Is T1) OrElse (TypeOf obj Is T2) etc and
(TypeOf obj IsNot T1) AndAlso (TypeOf obj IsNot T1) AndAlso (TypeOf obj IsNot T2) etc
being proposed to "syntactic sugered" to
( TypeOf obj Is { T0, T1, T2 } ) and
( TypeOf obj IsNot { T0, T1, T2 } ) respectively.
also should be noted this isn't restricted to generic type parameter T0,T1 and T2 are being used placemarkers for types in the examples.

[bandleader]

Though there ideas / proposals to extend the capabilities of Select and Is which could solve most of the patterns.'

@AdamSpeight2008 That's what I meant by pattern matching. If we do an Is operator which supports type matching, as well as OR possibilities in a group, then obj Is {TextBox, ListBox} will work out of the box, with no need to extend TypeOf...Is. I personally don't mind if you implement this as part of TypeOf...Is -- it's just that I think the team is against doing things in >1 place...

[gafter]

@AdamSpeight2008 The first step in designing a language feature is to open an issue on the vblang repository requesting or proposing the feature where it can be discussed by the community and the LDM. If and when the LDM believes it has converged on a language approach to the problem identified (note that the LDM starts by considering the problem to be solved), then (and only then) it makes sense to add a specification draft. This PR is premature.

[zspitz]

@bandleader Do we need pattern matching? Even if all we implemented was composable types, wouldn't that be enough?

[bandleader]

@zspitz No; there are tons of things that pattern matching can do (and does do in other languages) apart from checking types.

To be clear, your idea is very valuable and the use case is common. I'm just saying that it will anyway be implemented as part of pattern matching, and therefore, I'm not sure if the language team will want to additionally implement it in the TypeOf operator.

[AdamSpeight2008]

Prefer Proposal #481