Late final field inference

[sgrekhov]

According to the inference specification

The type of a final field which overrides/implements both a setter and a getter is inferred to be the return type of the combined member signature of said getter in the direct superinterfaces.
...
Note that late fields are inferred exactly as non-late fields. However, unlike normal fields, the initializer for a late field may reference this.

How the type of a late final field should be inferred? According to the above it should be inferred as a final non-late field. But in fact

class A {
  void set m1(String _) {}
  num get m1 => 3.14;
  void set m2(String _) {}
  int get m2 => 42;
}

class C extends A {
  late final m1 = 0; // Ok, inferred as num
  late final m2; // Error. The setter 'C1.m2' ('void Function(int)') isn't a valid override of 'A.m2' ('void Function(String)')
}

This behavior is OK, but perhaps it makes sense to adjust the specification and clarify that the type of a late final field with no initializer is inferred as a type of a non-final field?

[lrhn]

The behavior does look like it matches the quote, and we get the error that's needed to avoid unsoundness.
We can predict at inference time that it will be an error, so that's some bad inferring, even if it's specified.
There will be a setter, and the setter must satisfy the superinterface setter parameter.

In this case, it's not possible to infer any valid type.
There is no single type which is a subtype of int for the getter and supertype of String for the setter, so there is no way a single variable with one type can implement both.
So that's not the case for doing something more precise.

If we had:

abstract class A {
  int? get x;
  set x(int _);
}
class B implements A {
  late final x;
}

then ... it doesn't change much.
We can't use any proper supertype of the getter type as type.
We really only have the choices of int? and int - the intersection of the subtypes of the getter type and the supertypes of the setter type.

Using the getter type isn't wrong..

What do we actually do for non-final variables:

abstract class A {
  int? get x;
  set x(int _);
}
class B implements A {
  late final x;
}
class C implements A {
  var x; // 'C.x' ('dynamic Function()') isn't a valid override of 'A.x' ('int? Function()').
}

void foo(A a, B b, C c) {
  a.x.st<E<int?>>(); // Declared type, `int?`
  a.x = ctx()..st<E<int>>(); // declared type, `int`

  b.x.st<E<int?>>(); // Inferred type `int?`, getter's type.
  b.x = ctx()..st<E<int?>>(); // Inferred type `int?`, getter's type.

  c.x.anything; // is dynamic, inference failure?
  c.x = ctx()..anything; // is dynamic, inference failure?
}

extension<T> on T {
  void st<X extends E<T>>() {}
}
typedef E<T> = T Function(T);
T ctx<T>([Object? v]) => v as T;

So it's not like using the rules for non-final variables gives a better result in the one case where there is any other possible valid result.

That's the analyzer. CFE doesn't do the same thing. (DCC on DartPad, main branch.)

main.dart:6:14: Error: Can't infer a type for 'x' as the overridden members don't have a combined signature.
Try adding an explicit type.
  late final x;
             ^
main.dart:2:12: Context: This is one of the overridden members.
  int? get x;
           ^
main.dart:3:7: Context: This is one of the overridden members.
  set x(int _);
      ^
main.dart:9:7: Error: Can't infer a type for 'x' as the overridden members don't have a combined signature.
Try adding an explicit type.
  var x; // 'C.x' ('dynamic Function()') isn't a valid override of 'A.x' ('int? Function()').
      ^
main.dart:2:12: Context: This is one of the overridden members.
  int? get x;
           ^
main.dart:3:7: Context: This is one of the overridden members.
  set x(int _);
      ^

That seems to use the rules for non-final variables, and fails to infer a type in the same way.

If we should do something, it should probably be to directly make it a compile-time error to override a getter and setter with an untuped variable when the setter parameter type is not a subtype of the getter return type.
(Rule: Don't infer a type that is known to be an error in the same declaration anyway. Just err and say no type can be found. Users don't like being told that the error is something they never wrote.)