RFC: Go 2: user definable index operators

[metux]

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

[seankhliao]

while it doesn't specifically mention indexing, I think operator overloading should be folded into #27605

[metux]

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.

I wonder how @ianlancetaylor or @rsc, @robpike have to say about this.

[ianlancetaylor]

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.