You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Has this idea, or one like it, been proposed before?
Does this affect error handling?
Is this about generics?
Is this change backward compatible? Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit
Has this idea, or one like it, been proposed before?
Yes
Typed enum support has been suggested in #19814. That proposal has a overlapping use-case, which is to allow conversion to/from enumerated values and strings.
This proposal is different in that it's not limited to enums; it's about type parameterization using values. This proposal could be used to define an enum package (in or outside) the standard library to aid with enum conversion and validation, but it's not primarily a proposal for implementing enums.
Const parameters has been suggested in #65555. That proposal aims at allowing to create types using constant parameters (as an alternative or addition to typed parameters).
This proposal is different, and perhaps arguably worse, in that it isn't limited to constant parameters. The proposal is also different in the sense that it's aiming for a clear separation between type and value parameters.
Does this affect error handling?
No
Is this about generics?
Yes, it's about allowing type initialization to refer to a value.
Proposal
Sometimes, it would be useful to initialize a type that is initialized not only using type parameters, but also value parameters. This allow generic code to be written for multiple use-cases, such as:
Initialize generic types that reference static values. E.g. a model type could include a function TableName() string that return a static result.
Initialize generic enum-like types with conversion to and from an external representation by providing a two-way lookup value reference (see example) by implementing interfaces that are relevant to the target context. E.g. in the context of database fields, define a generic type with sql.Scaner and driver.Valuer implementations refering to a type parameterized translation lookup. In the context of an API model, implement encoding.TextMarshaller and encoding.TextUnmarshaller instead.
Initialize arrays or matrices of a specific size (maybe more complex).
Enum use-case
Goal: define an enum like value with minimal boiler plate (library code is allowed).
Current solution (no language change)
Library:
package enum
// Lookup provides a two-way lookup// between values of type T and strings.typeLookup[Tcomparable] interface{
Value(string) (valueT, okbool)
Name(T) (namestring, okbool)
}
funcMustCreateLookup[Tcomparable](map[T]string) EnumLookup{
// implementation doesn't matter.
})
package enum
// Lookup provides a two-way lookup// between values of type T and strings.typeLookup[Tcomparable] interface{
Value(string) (valueT, okbool)
Name(T) (namestring, okbool)
}
funcMustCreateLookup[Tcomparable](map[T]string) EnumLookup{
// implementation doesn't matter.
})
An attempt of supporting what's described in #65555. There could be reasons in which this is harder than the first case. I am not sure it's a priority use-case.
A type value parameter list declares the type value parameters of a generic type declaration; it can not be used by generic functions. The type value parameter list looks like an ordinary function parameter list except that the type parameter names must all be present and the list is enclosed in square brackets rather than parentheses. The declaration must come right after a type parameter list. If there are no type parameters, then an empty set of square brackets must precede the value parameter list.
Example (with a type parameter list prefix):
[T any][v T]
[][v string]
[][_ any]
Just as each ordinary function parameter has a parameter type, each type value parameter has a type.
Informal Change
Just like a function can have both input parameters and output parameters, a generic type can have both type and type value parameters. Both parameters are used to generate a concrete implementation. Type parameters are replaced by specific types, while type value parameters are replaces by a reference to a specific variable reference. That is, if you where to generate code for it, you would typically see that instances of the type parameters are replaced by the proper type reference, while references to values, are replaced by references to package scoped variables.
Orthogonality: How does this change interact or overlap with existing features?
It interacts with generic type declarations, by declaring a second parameter group.
Would this change make Go easier or harder to learn, and why?
I don't think it would make Go easier to learn. It's going to make it somewhat harder to learn generics in particular.
It might help deal with some pain-points if combined with the right standard libraries, such as easier enum handling.
Cost Description
Generics just got twice as complex.
You know have types declarations that need to point to variable declarations. The compiler guys will not like this; they may decide to quit Go altogether.
Should consider possible misuse. What's the worst code you can write with this feature?
Changes to Go ToolChain
Yes
Performance Costs
Unknown.
Prototype
I belie a ad-hock implementation could be written that depend on code generation.
Something similar to what was used for go generics, using .go2 or another file type format, could be used to scan the code and replace type value parameters with specific type implementations that replace the variable reference with a reference to a private package scoped variable; potentially one with a generated name.
The proto-type could be limited not to allow usage of the new generics across package borders, and could run before compilation. It could also require explicit use of type aliases for declaring types.
A final implementations should not have such limitaitons.
The text was updated successfully, but these errors were encountered:
Go Programming Experience
Experienced
Other Languages Experience
C, Python
Related Idea
Has this idea, or one like it, been proposed before?
Yes
Typed enum support has been suggested in #19814. That proposal has a overlapping use-case, which is to allow conversion to/from enumerated values and strings.
This proposal is different in that it's not limited to enums; it's about type parameterization using values. This proposal could be used to define an
enum
package (in or outside) the standard library to aid with enum conversion and validation, but it's not primarily a proposal for implementing enums.Const parameters has been suggested in #65555. That proposal aims at allowing to create types using constant parameters (as an alternative or addition to typed parameters).
This proposal is different, and perhaps arguably worse, in that it isn't limited to constant parameters. The proposal is also different in the sense that it's aiming for a clear separation between type and value parameters.
Does this affect error handling?
No
Is this about generics?
Yes, it's about allowing type initialization to refer to a value.
Proposal
Sometimes, it would be useful to initialize a type that is initialized not only using type parameters, but also value parameters. This allow generic code to be written for multiple use-cases, such as:
TableName() string
that return a static result.sql.Scaner
anddriver.Valuer
implementations refering to a type parameterized translation lookup. In the context of an API model, implementencoding.TextMarshaller
andencoding.TextUnmarshaller
instead.Enum use-case
Goal: define an enum like value with minimal boiler plate (library code is allowed).
Current solution (no language change)
Library:
Application:
Suggested solution (language change)
Library:
Application:
Matrix use-case
An attempt of supporting what's described in #65555. There could be reasons in which this is harder than the first case. I am not sure it's a priority use-case.
Current solution (not type safe)
Solution with language change (type safe)
Alternatively, if it's easier for implementation reasons:
Language Spec Changes
To be decided; early draft
Type value parameter declarations
A type value parameter list declares the type value parameters of a generic type declaration; it can not be used by generic functions. The type value parameter list looks like an ordinary function parameter list except that the type parameter names must all be present and the list is enclosed in square brackets rather than parentheses. The declaration must come right after a type parameter list. If there are no type parameters, then an empty set of square brackets must precede the value parameter list.
Example (with a type parameter list prefix):
[T any][v T]
[][v string]
[][_ any]
Just as each ordinary function parameter has a parameter type, each type value parameter has a type.
Informal Change
Just like a function can have both input parameters and output parameters, a generic type can have both type and type value parameters. Both parameters are used to generate a concrete implementation. Type parameters are replaced by specific types, while type value parameters are replaces by a reference to a specific variable reference. That is, if you where to generate code for it, you would typically see that instances of the type parameters are replaced by the proper type reference, while references to values, are replaced by references to package scoped variables.
A simple (and somewhat silly) example:
Is this change backward compatible?
Yes
Orthogonality: How does this change interact or overlap with existing features?
It interacts with generic type declarations, by declaring a second parameter group.
Would this change make Go easier or harder to learn, and why?
I don't think it would make Go easier to learn. It's going to make it somewhat harder to learn generics in particular.
It might help deal with some pain-points if combined with the right standard libraries, such as easier enum handling.
Cost Description
Changes to Go ToolChain
Yes
Performance Costs
Unknown.
Prototype
I belie a ad-hock implementation could be written that depend on code generation.
Something similar to what was used for go generics, using
.go2
or another file type format, could be used to scan the code and replace type value parameters with specific type implementations that replace the variable reference with a reference to a private package scoped variable; potentially one with a generated name.I.e.
would generatesomething like:
The proto-type could be limited not to allow usage of the new generics across package borders, and could run before compilation. It could also require explicit use of type aliases for declaring types.
A final implementations should not have such limitaitons.
The text was updated successfully, but these errors were encountered: