Document grammar of type literals on `Type`.

[acarstoiu]

I, for one, could not find a syntax accepted by the Dart parser that makes it possible to write a Type literal corresponding to a nullable type. For example, how would you compare a type parameter T to String?, because the natural expression

... T == String? ...

doesn't cut it for the parser, even when enclosed in parantheses❓

I had to write the condition like this

Type typeAsValue<Q>() => Q;
...
{
... T == typeAsValue<String?>() ...
}

I did check if this grammar issue was already reported - apparently not, which is also a surprise.

[rubenferreira97]

I don't know the specific reason why the parser rejects String? directly as a literal expression. It likely stems from legacy parser constraints or potential ambiguity with ternary/conditional operators in an expression context.

A cleaner workaround that avoids the potential runtime overhead of a helper function (if the compiler doesn't fully inline the call) is to use a generic typedef. This creates a compile-time alias, allowing you to reference the nullable type directly for comparison.

You can do this:

typedef Nullable<T> = T?;

void main(List<String> arguments) {
  test<String?>(); // Prints 'String?'
  test<String>();  // Prints 'String'
  test<int?>();    // Prints 'Other'
}

void test<T>() {
  // Now you can compare against Nullable<Type>
  if (T == Nullable<String>) {
    print('String?');
  } else if (T == String) {
    print('String');
  } else {
    print('Other');
  }
}

[ykmnkmi]

Best way to do this is using <T>[] is List<String?>. Reflection doesn't support nullable type literals too.

[lrhn]

Type literals can only use the syntax identifier or identifier<typeArgs>. The grammar didn't recognize anything else. You can't write a nullable type, function type, record type, or void as an expression. That's deliberate, it would make the grammar ambiguous, or at least harder to parse, both for compilers and human readers.

You can use a helper type-alias:

typedef TypeOf<T> = T;

Then you can write T == TypeOf<String?>.

I really, really recommend reconsidering any approach that requires you to use your literals or Type objects for anything. It's almost inevitably going to be fragile since it doesn't understand subtyping. (Type objects are dumb, they only understand ==, because all objects do, but simple equality is not something a type system with subtyping should ever be caring about.)

The <T>[] is List<String?> trick is better because it uses a subtype check. You can have helper functions like

class _Type<T> {}
bool isSubtype<Sub, Super>() => _Type<Sub>() is _Type<Super>;

so you can write if (isSubtype<T, String?>)

Trying to recognize the value of a type parameter is counter to the concept of generics, where you type the code generically, so the same code works for different types. Having the code then be different for different type arguments means it's not actually generic. I'd try to make a special function for the type that I want to special-case.

[acarstoiu]

The <T>[] is List<String?> trick is better because it uses a subtype check. You can have helper functions like

class _Type<T> {}
bool isSubtype<Sub, Super>() => _Type<Sub>() is _Type<Super>;

so you can write if (isSubtype<T, String?>)

You are thus indirectly confirming is to be the only "subtype-of" test in the language. Also, I cannot help noticing a small downside of these tricks (which I thank you both for): they build a value solely for performing an is predicate test, so it would better be as cheap as possible.

Trying to recognize the value of a type parameter is counter to the concept of generics, where you type the code generically, so the same code works for different types. Having the code then be different for different type arguments means it's not actually generic. I'd try to make a special function for the type that I want to special-case.

Don't worry, this test is made for an optional functionality within the parameterized class. Optional even if the test is passed.

[acarstoiu]

Type literals can only use the syntax identifier or identifier<typeArgs>. The grammar didn't recognize anything else. You can't write a nullable type, function type, record type, or void as an expression. That's deliberate, it would make the grammar ambiguous, or at least harder to parse, both for compilers and human readers.

And to the point, I was going to ask for the parser to recognize (<Type literal> ?) as a nullable type literal (with no effect if the literal already already indicates a nullable type), just like (<expression>,) builds a single item record. Sadly, this possibility is taken away by a pattern.

So the cheapest way is to define a parameterized type alias.
Could you then, please, integrate the statement "Type literals can only use the syntax identifier or identifier<typeArgs>." into the API documentation and link from there to the (overlooked) Typedefs page as the only means to "write a nullable type, function type, record type, or void as an expression", beside type arguments wrapped in <...>?
Thank you.