Rekkonnect
commented
1 year ago With further thought, due to constraints on nicely detecting the language from which a metadata type is built, it would be more appropriate to simply track and display the different namespaces that the user has solved the problem on.
This means that this feature would expand into allowing for example, 3 C# solutions, 2 F# ones and 2 VB ones. The distinction would only be the namespaces that contained those. Even with conflicting namespaces, assembly resolution would come into play, hinting that the same namespace could contain types with equal names, as long as they belonged to different assemblies.
The UX could be something like the following:
Year 2022
Day 15
Found 5 different solutions:
Opt | Namespace | Assembly
===============================================================
[0] | AdventOfCode.CSharp.Problems | AdventOfCode.CSharp
[1] | AdventOfCode.CSharp.Better.Problems | AdventOfCode.CSharp
[2] | AdventOfCode.FSharp.Problems | AdventOfCode.FSharp
[3] | AdventOfCode.FSharp.Simple.Problems | AdventOfCode.FSharp
[4] | AdventOfCode.VB.Problems | AdventOfCode.VB
It could occur that the same problem be solved in more than one languages in the same solution, as it will be visible from the dependencies of the final project. For instance, 2015/15 might be solved in both the C# and the F# solutions project, in which case a collision would occur.
The index should preferably add support for detecting the language in which the problem is solved. Either by explicitly specifying it in an assembly-wide attribute from a source generator on every project using the AoC# framework, or through some other way that utilitizes detection of the language the assembly was built in. Using clever and hacky tricks found online should be excluded from being a solution.