Unused private constructor doesn't trigger unused_*

[matanlurey]

Minimal reproduction:

void example(PublicClassPrivateConstructor? e) {
  print(e == null);
}

class PublicClassPrivateConstructor {
  PublicClassPrivateConstructor._();
}

I'm guessing there is an argument this is often a "hint" to prevent extends or with, which leads me to believe we need an @interface annotation - but it's also probably reasonable to use // ignore: unused_constructor for this purpose as well.

[matanlurey]

Interestingly enough, adding a factory constructor starts triggering:

void example(PublicClassPrivateConstructor? e) {
  print(e == null);
}

class PublicClassPrivateConstructor {
  factory PublicClassPrivateConstructor() {
    throw UnimplementedError();  
  }
  
  PublicClassPrivateConstructor._();
}

[srawlins]

Yeah it's intentional for the reasons you give.

[srawlins]

Want to change this to a request for @interface?

[matanlurey]

@srawlins I'm OK with you closing this as a dupe of #46331 in that case. Up to you.

[srawlins]

I'll keep this open as we should change the behavior soon for Dart 3.0 interfaces.

[lrhn]

It's not just a hint, it prevents the class from having an implicit public default constructor.
That means that having a single private constructor is a reasonable thing to do, even if nobody uses it.
(Today abstract interface can do the same thing - then it doesn't matter that the class has a default constructor, if you can't call it and can't use it as a super constructor. Used to be that the private constructor was the best way to achieve that.)

[srawlins]

Alright let's call it meaningful then.

[matanlurey]

Alright let's call it meaningful then.

I have an inverse read of the situation, now that we have abstract interface, an unused private constructor is dead code :P.

[bwilkerson]

While I see your perspective, the code serves a purpose. There's another (and maybe better) way to accomplish the same purpose, but that doesn't negate the fact that the code can't just be removed without making other changes.

The two styles are both valid Dart, and if would be irritating to a user that preferred the constructor approach to have diagnostics that they never intended to resolve.

I could argue that the lint ought to flag such a constructor if the class is already marked as abstract interface. I don't know whether we do.

In addition, we could have a lint to flag cases where a class could be marked with abstract interface. If we did add such a lint it should have a fix.

Or we could skip the lint and implement an assist that would convert the class and remove the constructor. It isn't clear to me that anyone would discover such an assist, however.

[lrhn]

If you can guarantee that the default constructor of an abstract interface class is not shown in DartDoc, then I'll agree that there is a better way. (But also don't want to migrate too much code for that, and we still do allow pre-3.0 code to exist, so unless the lint can behave differently for pre-3.0 code than for post-3.0 code, it's a problem.)