@protected should allow use in extensions

[plammens]

The @protected annotation should in my opinion allow use in extension methods:

class Class {
  @protected
  void protectedMethod();
}

extension Extension on Class {
  void extensionMethod() => protectedMethod();  // warning: invalid use of protected
}

Dart info

General info

• Dart 3.4.4 (stable) (Wed Jun 12 15:54:31 2024 +0000) on "windows_x64"
• on windows / "Windows 10 Home" 10.0 (Build 22631)
• locale is en-GB

Project info

• sdk constraint: '^3.4.0'
• dependencies: built_collection, cloud_firestore, collection, cupertino_icons, easy_debounce, equatable, firebase_auth, firebase_core, firebase_ui_auth, firebase_ui_oauth_google, flut ter, flutter_fancy_tree_view, flutter_local_notifications, flutter_localizations, flutter_riverpod, flutter_speed_dial, flutter_timezone, google_sign_in, intersperse, intl, meta, modal_bottom_sheet, package_info_plus, quiver, rrule_generator, skeletonizer, sliver_tools, stream_transform, timezone, url_launcher
• dev_dependencies: custom_lint, flutter_launcher_icons, flutter_lints, flutter_test, riverpod_lint, test
• elided dependencies: 2

[dart-github-bot]

Summary: The @protected annotation currently prevents extension methods from accessing protected members of a class, leading to an error message. The user proposes that @protected should allow access from extensions.

[lrhn]

Since @protected doesn't actually protect against access (you can just // ignore the warning if you want to), it may make sense to allow an extension to count as being equivalent to the type itself. The @protected annotation is intended to allow API that should only be used by other members of the same object. Extension members seem to match that, at least as intent.

Just blindly allowing it may leak API that is intended as protected into other libraries without any warning. If the other library is declared an extension method as a helper for themselves, maybe they shouldn't be using protected members for it. (Or maybe they should. It's impossible to say generally.) A compromise could be to allow access to @protected members from extension members that are in the same library as their on type (or its bound, if generic). Then it doesn't matter if a class declares its members as instance members or as extension members (declared in the same library), but if someone else tries to add extension members, they're not considered part of the class they're adding extensions on.

[plammens]

In my use case, I write the extensions in files different from the file where the base class is defined. The protected method is intended to be used in implementing other methods of the subtype, but is not meant to be called directly by external users.

I have some arbitrary data objects, and then a generic class Snapshot<T> which holds a data object of type T and additional database information such as id and location of the object in the database. My data classes are immutable because I make changes directly to the database. For that I need to have access to the database info, so any mutation methods should be in Snapshot<T> and not in T. The problem is that each data class has different things you can modify, so I can't just add everything to the generic Snapshot.

What I do is, whenever I write a data type T, I also write an extension of Snapshot<T> with the relevant mutation methods alongside it. Internally, these methods call an update method that takes a map of field names (strings) to field values. The update method is in the generic Snapshot and marked as protected, because external users shouldn't use it directly, to avoid breaking encapsulation and to profit from type safety: each data class is responsible of how its own data is serialized/deserialized, including field names etc.

Currently, the uses of update inside extensions of Snapshot are marked with a warning.