-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: spec: create builtin interfaces, let builtin types fulfill them #8303
Labels
FrozenDueToAge
LanguageChange
Suggested changes to the Go language
v2
An incompatible library change
Milestone
Comments
Can you please summarise what you are asking for ? I believe that you are asking for some kind of interface for builtin types, the example you give is bool. But the reason for this request is to express a third case, true, false and not set. How is your proposal materially better than the existing solutions of using a *bool. This is what you would get, the ability to set this boolean interface type to nil, if I understand your proposal. Labels changed: added languagechange. Status changed to WaitingForReply. |
being not a native speaker I had chosen some wrong wordings: - "There are times more often than not": remove "more often than not" - "The optional aspect is expression via the fact": instead: "Since any interface can be nil, this is a way to express optionality". - "builtin/interf being a package that has to be included": instead "a package that has to be imported" I apologize. |
That is right the reason is to express the builtin value and not set (nil). The solution asked for solves this by providing an interface for each of the mentioned builtins that could be used instead of the builtin in such cases. Please have a look at google/go-github#19 to see how hary the implications are when using pointers to the builtin types. That simply does not scale well for complex structs and libraries. The proposal would allow library developers to have - a faster implementation, since the builtin->interface->interface method path could be optimized away by the compiler - a idiomatic solution with good type signatures and less code - to make better API for the consumer of the library, that is easier to use, less error prone and more flexible What I ask for is, to have a special interface for each of the meantioned builtin and to have the compiler let each of the meantioned builtin fulfill its interface without overhead. |
Also is it NOT about having methods on predeclared types. In fact there should not be any method attached to a builtin. You should NOT be able to do e.g. "a".String() Instead it is only that there are builtin interfaces that happen to be satisfied and optimized by their corresponding builtin type. I might sound unusual but it would be a nice fit to go. |
There are two problems that are not served well by Go is it stands today: 1. Usage of optional builtin types as struct fields and func parameters are cumbersome leading to hard to maintain incompatible ad hoc solutions in packages (see mentioned ticket and blog post) 2. There is currently no way to have a type that is an interface and is satisfied by a builtin without having to create wrapper types that are also ad hoc, package specific and cumbersome. The proposal offers a solution to both problems. |
Please have a look at this package: https://github.com/go-on/builtin here I have implemented it on a package level with wrapper types. It would be nice to have the above mentioned compiler support which would reduce overhead to 0. But if that is considered a too big change for the compiler, please consider integrating this package into the standard library. That would be no language change but had still the benefit of having standardized interfaces for other packages and a recommended way to solve optionality. |
This proposal is a way of adding optional types to Go: a type that can hold either a value or an indication that there is no value. I'm going to close this as a dup of #19412, where there is a lot of discussion about optional types as a particular kind of sum type. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
FrozenDueToAge
LanguageChange
Suggested changes to the Go language
v2
An incompatible library change
The text was updated successfully, but these errors were encountered: