// Copyright 2020 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

// go2go is a command for trying out generic Go code.
// It supports a small number of commands similar to cmd/go.
//
// This tool was intended for experimental use during the development
// of the generics proposal, and is no longer maintained.
//
// Usage:
//
//	go2go [options] <command> [go2go flags] [arguments]
//
// Commands:
//
//      build      translate and then run "go build packages"
//      run        translate and then run a list of files
//      test       translate and then run "go test packages"
//      translate  translate .go2 files into .go files for listed packages
//
// A package is expected to contain .go2 files but no .go files.
//
// Non-local imported packages will be first looked up using the GO2PATH
// environment variable, which should point to a GOPATH-like directory.
// For example, import "x" will first look for GO2PATHDIR/src/x,
// for each colon-separated component in GO2PATH. If not found in GO2PATH,
// imports will be looked up in the usual way. If an import includes
// .go2 files, they will be translated into .go files.
//
// The go2go flags are shared by the build, run, test, and translate commands:
//
//	-tags tag,list
//		a comma-separated list of build tags to consider satisfied during the
//		build. For more information about build tags, see the description of
//		build constraints in the documentation for the go/build package.
//
// There is a sample GO2PATH in cmd/go2go/testdata/go2path. It provides
// several packages that serve as examples of using generics, and may
// be useful in experimenting with your own generic code.
//
// Translation into standard Go requires generating Go code with mangled names.
// The mangled names will always include Odia (Oriya) digits, such as ୦ and ୮.
// Do not use Oriya digits in identifiers in your own code.
//
// Because this tool generates Go files, and because instantiated types
// and functions need to refer to the types with which they are instantiated,
// using function-local types as type arguments is not supported.
// Similarly, function-local parameterized types do not work.
// These are deficiencies of the tool, they will work as expected in
// any complete implementation.
//
// Similarly, generic function and type bodies that refer to unexported,
// non-generic, names can't be instantiated by different packages.
//
// Because this tool generates Go files, and because it generates type
// and function instantiations alongside other code in the package that
// instantiates those functions and types, and because those instantiatations
// may refer to names in packages imported by the original generic code,
// this tool will add imports as necessary to support the instantiations.
// Therefore, packages that use generic code must not use top level
// definitions whose names are the same as the names of packages imported
// by the generic code. For example, don't write, in package scope,
//
//     var strings = []string{"a", "b"}
//
// because if the generic code imports "strings", the variable name will
// conflict with the package name, even if your code doesn't import "strings".
// This is a deficiency of the tool, it will not be a deficiency in
// any complete implementation.
package main