Should inline class members with same names as those of the field be targets of lint?

[Cat-sushi]

For the same reason of prohibiting to override toString(), it is very confusing.

inline class Id {
  final int value;
  Id(this.value);
  bool get isEven => value.isOdd; // lying. Should this be a target of lint?
}

main() {
  Id id = Id(123);
  print(id.isEven); // true (deceived)
  dynamic d = id;
  print(d.isEven); // false
}

[lrhn]

The difference is that inline class types are all subtypes of Object, or at least Object?, and are likely to be used in a way where code will call toString at that type, and not hit an inline class method of the same name. The five members that every object has are also called directly by the language, and we've never specified which type those methods are called at.

The inline class shown here is not assignable to int, so it's not as easy to get into a position where someone expects the inline class isEven getter to be used, but will actually use the instance method.

If we do allow an inline class to implement its representation type, then that problem comes up again.
We are considering whether we should be allowed to shadow inherited instance methods then. But there are reasonable use-cases, so it's not as clear cut.

[Cat-sushi]

If we do allow an inline class to implement its representation type, then that problem comes up again.

Yes, I worry about that, as well.

[eernstg]

I think it would be quite natural to have a mechanism to ensure that it is documented when a particular declaration is a redeclaration of some other implementation. (A redeclaration is the relationship which is similar to overriding, except that it is statically resolved.)

We could probably use the word redeclare to do this (that seems to be virtually non-existing in Dart code today), and have a declaration in a suitable library such that it can be used as metadata:

inline class Id implements int {
  final int value;
  Id(this.value);

  @redeclare
  bool get isEven => ...; // Presumably, this would be a legitimate implementation.
}

main() {
  Id id = Id(123);
  print(id.isEven); // (1)
  dynamic d = id;
  print(d.isEven); // (2)
}

The @redeclare metadata would play a role which is similar to the role which is currently played by @override. So we'd have a lint to support the consistent use of @redeclare on every inline class member which is a redeclaration of a member declaration in one of its superinterfaces (inline or non-inline).

A developer or an organization could make the choice to disable that lint and never use @redeclare (or @override for that matter), but I would assume that the Dart community develops a near-consensus about the need to use @redeclare or not.

In any case, I think we should assume that the redeclaration is appropriate for some purpose, and also that it is, in general, correct to invoke Id.isEven on a receiver of type Id. The developer who wrote that declaration and included the @redeclare metadata should be able to explain exactly why it's a good thing to have that declaration with that name.

Of course, we can do id as dynamic to eliminate the inline type, but that's just a fact of life with inline classes: They do not involve the cost of creating and handling a wrapper object, but the other side of that coin is that id as T will work on the underlying representation type (e.g., id as int would not throw).

With that, I'd say that the invocation at (1) is appropriate: It runs the code in Id.isEven, and it should run exactly that code.

The problematic part is id as dynamic: This will eliminate the typing of that object as an Id, and even though it's possible, it is certainly not likely to be a good practice. If we have decided that we'd want to use a particular perspective on the representation object by using the type Id rather than int, then we shouldn't destroy that typing.

[srawlins]

@pq is well into implementing @redeclare and static analysis for it.

[Cat-sushi]

Isn't @redeclare for my original issue?

import "package:meta/meta.dart";

extension type Id._(int value) {
  Id(this.value) : assert(value >= 1);
  @redeclare
  bool get isEven => value.isOdd;
}

line 6 • The getter doesn't redeclare a getter declared in a superinterface.

[albertms10]

Isn't @redeclare for my original issue?

You should instead declare the extension type to implements int so it can inherit the members of int:

import "package:meta/meta.dart";

extension type Id._(int value) implements int {
  Id(this.value) : assert(value >= 1);
  @redeclare
  bool get isEven => value.isOdd;
}

[Cat-sushi]

My point is that, even in case that a extension type doesn't implement the representation type, declaring a member with same name of one of it's representation type is confusing.

[lrhn]

It may be confusing, and it may be exactly the thing you want to do.

If the lint triggers even if the extension type wouldn't have exposed a member with that name otherwise, then it's not so much a redeclare as it is a name coincidence. The annotation would be required because of something that's not visible in the API anyway.

I'm not sure it's worth it.
I'd at least make it a different lint, and not one that's enabled by default (recommended)