Would like a way to avoid raw generic types

[matanlurey]

Tangentially related to #31410.

While migrating swaths of internal code (probably in the tens-of-thousands-of-lines, myself), one of the most common errors users are running into when migrating to Dart2 are so-called "naked" raw types (is there a better name?). For example:

// Works as the user intended.
// List<int> x = <int>[1];
var x = [1];

// Does _not_ work as the user intended.
// List<dynamic> x = <dynamic>[1];
List x = [1];

Here is a more extreme example:

typedef Iterable<CacheEntry<K, V>> CacheEvictionFunction<K, V>(
  List<CacheEntry<K, V>> entries, 
  int entriesToBeTrimmed,
);

class CacheConfig {
  // In Dart1 this was "fine".
  // In Dart2 this fails, quite late, at runtime:
  // 
  // CacheEvictionFunction<dynamic, dynamic> "inferred"
  final CacheEvictionFunction _evictionImpl;

  CacheConfig(this._evictionImpl);
}

---

My 🔥 take: In Dart 2 + some flag, "raw" types that are implicitly dynamic should:

• Be a compile-time error ("You must specify a type or ")
• Work similar to Java's <?> (wildcard operator). That would mean:

// --no-implicit-dynamic
//
// List<int> x = <int>[1];
List x = [1];

// --no-implicit-dynamic
//
// Compile-time error: Must specify a type 'T' for List<T>
List x;

// --no-implicit-dynamic
//
// OK.
List<dynamic> x;

... if we are accepting name nominations, I nominate --strict-raw-types.

[matanlurey]

Related to #32978, also.

I'd also love to see Null be an explicit type, not an inferred one.

[jonahwilliams]

The combination of type inference and naked types is very unintuitive. It seems like "well I am providing more information to Dart, so it should infer better."

[munificent]

so-called "naked" types (is there a better name?)

Java calls them "raw types", which I hear on the Dart team sometimes.

My 🔥 take: In Dart 2 + some flag, "naked" types that are implicitly dynamic should:

Be a compile-time error ("You must specify a type or ")

I agree, it should be a compile error. We need to be clear about the several different places a raw type (or a thing that looks like a raw type) can appear. Here's the behavior I'd like:

// Error, raw type in annotation:
Set a = null;

// Error, raw type nested in annotation:
List<Set> b = null;

// No error, bare class name has type arguments inferred:
Set<int> c = new Set();

// Error, could not infer type argument for bare class name:
var d = new Set();

// Error, type inference does not fill in "half-complete" type annotations:
List<Set<int>> e = new List<Set>();

As for naming the flag, maybe --strict-raw-types?

[matanlurey]

@munificent Thanks. I updated my post/title to use the nomenclature "raw".

I also like --strict-raw-types more, so 👍

[jmesserly]

RE:

// Does _not_ work as the user intended.
// List<dynamic> x = <dynamic>[1];
List x = [1];

If someone writes that, they can only use x as a List<dynamic>, so why would you need a more precise list type to be reified? If it's because of an implicit cast later on, that suggests the problem is really with implicit casts. Consider using --no-implicit-casts.

The rationale for preferring downwards inference type was cases like this:

List<Object> x = [1];

At the time most people wanted that to pick <Object> rather than <int>. Similarly:

List<dynamic> x = [1];

So dynamic kind of fell out of that. We also don't have a distinction between List and List<dynamic> in the language, they are equivalent.

That said I do think raw generic types are a problematic area in Dart 2, and it would be nice to find another interpretation for them.

BTW, you could use --no-implicit-dynamic. It enforces a few things like:

• no raw generic types
• no implicit dynamic parameters/variables
• no implicit dynamic type arguments

We could split that up pretty easily, if some of those are easier to enforce/more urgent than others.

[jmesserly]

CC @leafpetersen @lrhn

[matanlurey]

@jmesserly:

RE:

// Does _not_ work as the user intended.
// List<dynamic> x = <dynamic>[1];
List x = [1];

If someone writes that, they can only use x as a List<dynamic>, so why would you need a more precise list type to be reified? If it's because of an implicit cast later on, that suggests the problem is really with implicit casts. Consider using --no-implicit-casts.

That might "fix" the problem, in that, the user will know they are likely making a mistake, but I don't see any reason to treat List (raw) as List<dynamic>. It's just doesn't work in Dart2 almost at all, so it seems like a bug not a feature.

I think --strict-raw-types should either change the semantics or raw types, or ban them.

The rationale for preferring downwards inference type was cases like this:

List<Object> x = [1];

At the time most people wanted that to pick <Object> rather than <int>. Similarly:

List<dynamic> x = [1];

So dynamic kind of fell out of that. We also don't have a distinction between List and List<dynamic> in the language, they are equivalent.

An explicit List<dynamic> or List<Object> makes total sense to me.

That said I do think raw generic types are a problematic area in Dart 2, and it would be nice to find another interpretation for them.

BTW, you could use --no-implicit-dynamic. It enforces a few things like:

• no raw generic types
• no implicit dynamic parameters/variables
• no implicit dynamic type arguments

We could split that up pretty easily, if some of those are easier to enforce/more urgent than others.

Definitely. I don't know what process is in place for evolving the language outside of being on the language team at this point, but definitely flags around downcasts, dynamic, and raw types are really desirable. It would be nice to have an idea of where the language is going and try to create flags that guide the user towards that path.

[jmesserly]

Definitely. I don't know what process is in place for evolving the language outside of being on the language team at this point, but definitely flags around downcasts, dynamic, and raw types are really desirable. It would be nice to have an idea of where the language is going and try to create flags that guide the user towards that path.

yeah that's a good question ... IDK either. Hopefully it's on their radar. :)

At least technically speaking, it's not hard to add a flag to Analyzer/CFE for this sort of thing, if we want to experiment.

[munificent]

Definitely. I don't know what process is in place for evolving the language outside of being on the language team at this point, but definitely flags around downcasts, dynamic, and raw types are really desirable.

It's still being sorted out. Right now, basically everyone is just trying to get Dart 2 out the door. Once that's settled down, @leafpetersen and @lrhn will start figuring out what the evolution process looks like.

[leafpetersen]

We'll be looking at stricter lint flags for things like this. A question for @matanlurey : how do you feel about raw types with bounds? That is, if you have:

class A<T extends num> {
}

void main() {
  A x;
}

then we currently treat A as if it was A<num>. Would you want to forbid this as well, or only when it produces dynamic?

[matanlurey]

@munificent:

It's still being sorted out. Right now, basically everyone is just trying to get Dart 2 out the door.

Oh sure. Just wanted to make it clear to others reading this post that this isn't any sort of formal language proposal, just a bug :)

@leafpetersen:

How do you feel about raw types with bounds?

I don't use them as much as others internally. I guess as long as the bounds is not Object/dynamic/void/Null then it might be OK.

At the same time I've been debugging issues like the following:

class ProtoContainer<T extends GeneratedMessage> {
  T data;
}

void main() {
  // In reality this isn't what users wanted, because they expect `UserMessage` or something else.
  var container = new ProtoContainer();
}

... I don't know if its possible, but maybe a way to indicate that T is a bounds, but not a default value. I know Flutter (tries) to use @optionalTypeArgs as an indicator for the reverse of this.

[matanlurey]

Hit another case internally. Accidental omission of type parameters extending/implementing:

abstract class HasValue<T> {
  T get value;
}

class WizBang extends HasValue {
  @override
  String get value => 'WizBang';
}

This is totally valid code, and nothing is flagged in the analyzer or otherwise.

At runtime, trying to use a WizBang as a HasValue<String> (or similar) fails. It took quite a bit of groking to finally understand that HasValue had a type parameter T that was omitted. I'd like to see our hypothetical --strict-raw-types warn if a type with type parameters is implemented without bounds or "passing through" params:

// OK
class WizBang extends HasValue<String> {}

// OK
class WizBang<T> extends HasValue<T> {}

// Still OK, at least it is explicit
class WizBang extends HasValue<dynamic> {}

// BAD
class WizBang extends HasValue {}