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
This is just an draft for discussion, not a formal proposal yet.
Author background
experienced, already touched toolchain code (also packagjng it for various distros)
other languages: too many to list'em all ;-)
Related proposals
haven't found similar proposal yet
no impact on error handling or generics
Precedence in other languages
python translates index operator to get() and set() methods
any class can implement them and so provide index operator
IOW: the [xxx] notation is just syntactic sugar for method calls
c++ allows custom operator implementations, which also go down to function/method calls, under the hood
Proposal
add support for user defined index operations ([foo]), these are routed to function/interface calls
helpful for reducing boilerplate for typical index-like operations
by employing interfaces, consumer code can be made agnostic of the actual type its operating on, while still using the compact slice/map-like syntax
by implementing corresponding interface on maps or slices themselves, those can be directly used whereever the that interface is demanded
How does it work:
when compiler encounters an index access on some custom type (or interface) it looks for a matching getter/setter function (exact naming scheme yet to be defined)
the compiler just rewrites it to a direct getter/setter call (ast transformation) and tries to resolve the function call the usual way.
so now, instead of foo.Get(bar) one can just write foo[bar], as well as foo[bar] = x instead of foo.Set(x)
the getter actually returns the value type as well as an ok flag
Yet leaving out iterators, since that's orthogonal to index operator and IMHO should be done independently.
Compatibility:
existing code remains uneffected
side effect: previously broken (non-compilable) code could become valid (if there happens to be an existing function that looks like a getter/setter by accident), but the practical risks should be quite zero.
error messages on broken code (trying index access on type that doesnt support it) might look differently - might complain on missing function now (depending on actual implementation). OTOH, that might be actually more useful than harmful, by giving the dev better hints on what he shall do, if he really wants index access
Costs
adds a little bit more complexity to the language itself
readers of source, who dont know this feature yet, might wonder how code using it could ever work/compile at all
affected tool: only those who actually with compiling (not just formatting etc)
tiny increase of compile time for code using that feature: at the point build breaks now, we'll have little ast transformation and continue compiling
no runtime overhead
The text was updated successfully, but these errors were encountered:
while it doesn't specifically mention indexing, I think operator overloading should be folded into #27605
No, this is quite different. The one you've mentioned deals with arithmetic operators. And explicitly demands the operants to be immutable, which totally contradicts the index operator, since changing elements belongs to its sole purpose.
Oh, and closing the ticket (whose sole purpose is starting a discussion) without any discussion is quite the opposite of opensource culture.
We are not going to support overriding the [] operator without support overriding of other operators. All the same problems arise for both kinds of overriding. So I think that de-duping this proposal is correct.
I appreciate that you are looking for a discussion. But we've found that GitHub issues are not a good place for that. They lack threading and if many people comment then comments are hidden by default and difficult to find in practice, leading to constant repetition. The proposal process is really for specific proposals. For discussions, please use a forum like golang-nuts. Thanks.
This is just an draft for discussion, not a formal proposal yet.
Author background
Related proposals
Precedence in other languages
Proposal
How does it work:
Compatibility:
Costs
The text was updated successfully, but these errors were encountered: