#Go to converter code
As an example, all relevant code samples from the " Tour of Go" have been converted to C#, see converted code. Sets of common Go sample code have been manually converted to C# using the current C# Go Library. Iterating through each of these simple use cases improves overall automated code conversion quality. NET 5.0 and C# 9.0.Ĭurrently, work to improve code conversions is progressing by walking through each of the behavioral testing projects. Recent ActivityĬonverted code now targets.
A manually created file that implements the partial method can now be added that will exist along side the auto-converted files and not be overwritten during conversion. For example, the builtin Go library functions will always require some special attention since many of its features are implemented outside normal Go code, such as with assembly routines.Ī strategy to automate conversion of native system calls in Go code, i.e., a function declaration without a body that provides a signature for a native external function, is to create a partial method in C# for the native call. As the project progresses, there will be a merger of automatically converted code and manually converted code. Note that go2cs simple conversions currently depend on a small subset of the Go source library, src/gocore, that was manually converted. This log should help lay out a road map of remaining tasks. Not all converted standard library code will compile yet in C# yet - work remaining to properly parse and convert all Go source library files, with its many use cases and edge cases, can be inferred by examining the warnings in the build log for this initial conversion.
#Go to converter full
These conversion successes are notable milestones in that they represent full successful conversions of the entire Go source library using the ANTLR4 Golang grammar without failing.
Project Status Automated Code Conversion of Go Standard LibraryĪ few initial conversions of the full Go source code have been completed, you can find the latest results in the repo: Even so, the philosophy is to always attempt to use managed code, i.e., not to lean towards native code libraries, regardless of possible performance implications. If there is no possible way for managed code to accomplish a specific task, an option always exists to create a native interop library that works on multiple platforms, i.e., importing code from a.