TLDR: Language should provide additional constructs to interact with private code. Am I the only one that feels like this all just points out to flaws of the l

TLDR: Language should provide additional constructs to interact with private code. Am I the only one that feels like this all just points out to flaws of the language itself? We should not have to consider changing private to public just because we want to test that function. Moreover I'v seen comments on docs.microsoft.com along the lines "not to be used", "for internal use only" etc that may be a result of language shortcomings. C# has this attribute InternalsVisibleToAttribute[1] where you open up all your internal stuff to other (test) assembly that solves one of the problems: your test assembly accessing YOUR code assembly. Now for the wishlist. The issue with InternalsVisibleToAttribute is that the assembly author controls this. I'd like to control this as a consumer too. Given that (citation) "The idea is that when writing library code you couldn’t possibly know what method your clients will want to use ahead of time, and defaulting to private methods will cause more problems for you and your clients than defaulting to public (or protected)." - so why not take responsibility to myself of using code that may break in next update? Like PrivateVisibleFromAttribute. Or a language construct like unsafe {}, but private {}/internals {} where intellisense will happily list all private/internal methods. Maybe not a good idea for all cases, but I can see this useful: "that library X won't need many updates and it has that complex function I'd like to use to exactly mimic functionality X". Or: this legacy system written 20 years ago won't have any updates, but I must implement XYZ, part of which already private functions by original developers provide. Or I may want to extend that private class, override with my functionality (re-using parts of that code) and provide bindings for runtime to use MyVendorClass instead of VendorClass. The thing is, you can do this with C# Reflection (access private members), but it's cumbersome. Better have language provide necessary tools and most of this discussion wouldn't happen as test assembly will happily tie into internals. [1] https://docs.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.internalsvisibletoattribute?view=net-6.0 https://docs.microsoft.com/en-us/dotnet/api/system.runtime.c...