Skip to content

BestFriend on public members ought to complain #2415

@TomFinley

Description

@TomFinley

We have the best friend attribute introduced in #1520, which is great, but sometimes I or someone makes a mistake and puts it on a public class. This is harmless, has no visible effects, but is just a bit odd and definitely not intended usage.

At least for me, the procedure is this: I make something public become [BestFriend] internal, but then I realize something is a bit more complicated than I thought, and I decide to delay that specific internalization work until some other conditions are met. (E.g., in #2404, I internalized IPredictorProducing, but then realized that the problems with calibrators represented a hard barrier, so I wrote #2378 to capture those difficulties, and changed it back to public, until that is resolved.) The trouble is sometimes I leave the [BestFriend] behind. This has happened multiple times.

It might be nice, though hardly essential, to have [BestFriend] itself be analyzed to see that any usage of it is not applied to any publicly accessible thing. This is not actually essential per se, it's just a code cleanliness type of thing.

This hypothetical work would go in Microsoft.ML.InternalCodeAnalyzer.

Metadata

Metadata

Assignees

Labels

nitNeeds a really small fix

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions