proposal: Go 2: extend types out of package where it is defined. #37742

leaxoy · 2020-03-08T01:40:11Z

In modorn language, like rust, swift, dart, programers can extends types in user code. In rust, it's impl Foo for Bar, in swift, it's extension Foo, in dart, it's extension Foo on Bar. The extension syntax give ability to extend any types in a simple way. It's powerful and useful. But now in Go, we can't achieve this any way.
In Rust way:

// this is user mod
impl ToInt for String {
    fn to_int(&self) -> Result<isize, Error> {}
}

In Swift way:

extension Int {
    func as_double() double {
    }
}

In Dart way:

extension NumberParsing on String {
  int parseInt() {
    return int.parse(this);
  }
  // ···
}

Existing way.

The existing way to achieve this is define new types or embed types in another types.

1. Define new types. For example:

in package a we have a type A:

package a
type A struct {}

in package b, if we want extend a.A, we must define a new types

package b
type B a.A

and then:

func (b B) Foo() {
}

but when using a.A, we must transform to b.B, it's annoying and not required if we have the ability to extend types out of package where it is defined.

2. Another way is embed in another type

in package a

package a
type A struct {
    ...
}

and in package b

package b
type B struct {
    a a.A
    // or 
   a.A
}

then

func (b B) Foo() {
    b.a.XXX()
    // or
   b.XXX()
}

it's also need wrap a.A to b.B to give an extended method Foo().

Proposal way

At this background, I proposal add ability to extend types out of package where it's defined. There are some syntax.

1. Normal syntax without any breaking syntax.

package b

import "a"

func (a *a.A) Foo() {

}

the only change is *A -> *a.A.

2. Add new keyword like `extend` or `ext`.

package b

import "a"

extend func (a *a.A) Foo() {}

extend func (a *a.A) Bar() {}

the extend keyword before func is to describe method Foo and Bar is extension method.

3. Like 2 add new keyword but place it before method name.

package b

import "a"

func (a *a.A) + Foo() {}

func (a *a.A) + Bar() {}

the + means this method is additional.

Usage

The above syntax give some way to achieve this, the following will give example how to use it.

1. use old `_` import syntax

package main

import (
    "a"
    _ "b"
)

// now we can use `a.A.Foo`
func main() {
    var a a.A
    a.Foo()
}

The text was updated successfully, but these errors were encountered:

ianlancetaylor · 2020-03-08T05:11:12Z

This has been suggested before, though I can't locate any earlier conversations.

The problem is interface types. If a type is defined in package a, adding a method in package b can mean that the type implements interfaces that it did not implement before. That means that conversions to interface type will change. When should it change? Should all types created in package a now implement the new interface? How should conversion in and out of interface{} work? How should type reflection work?

beoran · 2020-03-08T14:15:39Z

Moreover, this makes methods hard to locate. If I have a foo.Bar them now I can be sure that all methods of Bar are defined in the package foo, and that there can be no others.
As you showed yourself, the way to do this in Go is to make new types. This is "the right thing" to do in such a situation, and if other languages don't enforce this, I would say those languages get it wrong.

urandom · 2020-03-08T16:08:03Z

Previous discussion
#21401

urandom · 2020-03-08T18:02:13Z

Perhaps a different take to solve this would be to build on top of the underlying type syntax.

In Go, you can create a type from an underlying type, but lose the underlying type's methods:

type Foo bar.Bar

You can also create a type alias which "inherits" the methods of the "underlying" type, because that is not really a new type:

type Foo = bar.Bar

For discussion's sake, what about creating new types from an underlying type, which also "inherit" that type's method, and perhaps, implicit conversion between the new type and extended type can also be allowed:

type Foo + bar.Bar

Foo will be a completely new type that way, so there won't be any gotchas.

leaxoy · 2020-03-09T01:25:41Z

This has been suggested before, though I can't locate any earlier conversations.

The problem is interface types. If a type is defined in package a, adding a method in package b can mean that the type implements interfaces that it did not implement before. That means that conversions to interface type will change. When should it change? Should all types created in package a now implement the new interface? How should conversion in and out of interface{} work? How should type reflection work?

This is indeed a problem! Can we create a virtual type for reflect and expose user the original type, this is just an idea.

leaxoy · 2020-03-09T01:31:50Z

Moreover, this makes methods hard to locate. If I have a foo.Bar them now I can be sure that all methods of Bar are defined in the package foo, and that there can be no others.
As you showed yourself, the way to do this in Go is to make new types. This is "the right thing" to do in such a situation, and if other languages don't enforce this, I would say those languages get it wrong.

Maybe we do some trade off, just refer rust implementation, rust can add new method in mod a to String, user code just do use crate::a::SomeTrait to give ability to String type.
In this case, we must explicitly import package a to give ability to string or SomeType. Like the usage section shows.

leaxoy · 2020-03-09T01:44:06Z

Perhaps a different take to solve this would be to build on top of the underlying type syntax.

In Go, you can create a type from an underlying type, but lose the underlying type's methods:
type Foo bar.Bar
You can also create a type alias which "inherits" the methods of the "underlying" type, because that is not really a new type:
type Foo = bar.Bar
For discussion's sake, what about creating new types from an underlying type, which also "inherit" that type's method, and perhaps, implicit conversion between the new type and extended type can also be allowed:
type Foo + bar.Bar
Foo will be a completely new type that way, so there won't be any gotchas.

Thanks for the suggestions, but all of them have limits.
The first solution, new type will lose original method.
Second one, type alias is just an alias of original type, we can't add new method on it, this not solve type extension problem.
Last one, at first glance it seems feasible. But in my opinion, + can be replaced by with, because + means the same type in both left, right side, with means additional property or constraint.

ianlancetaylor · 2020-03-10T21:55:35Z

@urandom Thanks for finding the earlier discussion.

@leaxoy Is there anything new in this issue that is not covered by the discussion in #21401?

maj-o · 2020-03-14T22:12:12Z

@urandom this thing with + would mean: if I "derive" my type from e.g. int, I could use operators like + in my "derived" type? - I don't think so. Unless operators are handled like methods or interfaces.
@leaxoy Go is not object-orientated in this way, Go is more likely method-orientated. In Go You would simple implement your interface, regardless which type (struct) implements this interface (or better said: for which class this interface is implemented), as long as the method simply exists - it works. For instance the interface Reader. It works very well. If You want to extend it (The Go way is! Do not change the the class (struct), but the targeted interface), You may introduce an interface ReadWriter (Which also already exists but is a good example and works very well) - at this point - You have Your wished extension. You simply declare an interface (old interface (Reader) and Your "extension" (Writer) and get ReadWriter). The main goal of Go is, that every class implementing this can be used at interface points. Great isn't it? - So Your extended class can be used and every other class Implementing the same interface (maybe a different database backend or even a greater change). It will simply work, if the underling methods work (what is simply to test).

urandom · 2020-03-14T22:41:51Z

@maj-o you already can use operators that work on your underlying type with your type

ianlancetaylor · 2020-03-17T21:16:44Z

Based on the discussion about this is similar to #21401 which was closed. Therefore this is a likely decline. Leaving open for four weeks for final comments.

neakor · 2020-04-07T03:21:17Z

Would love to have this.

ianlancetaylor · 2020-04-07T21:04:41Z

No change in consensus. Closing.

gopherbot added this to the Proposal milestone Mar 8, 2020

gopherbot added the Proposal label Mar 8, 2020

leaxoy changed the title ~~proposal: Go 2, extend types out of package where it is defined.~~ proposal: Go 2: extend types out of package where it is defined. Mar 8, 2020

ianlancetaylor added v2 A language change or incompatible library change LanguageChange labels Mar 8, 2020

griesemer mentioned this issue Mar 10, 2020

proposal: Go 2 review meeting minutes #33892

Open

ianlancetaylor added the Proposal-FinalCommentPeriod label Mar 17, 2020

ianlancetaylor closed this as completed Apr 7, 2020

golang locked and limited conversation to collaborators Apr 7, 2021

gopherbot added the FrozenDueToAge label Apr 7, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

proposal: Go 2: extend types out of package where it is defined. #37742

proposal: Go 2: extend types out of package where it is defined. #37742

leaxoy commented Mar 8, 2020 •

edited

ianlancetaylor commented Mar 8, 2020

beoran commented Mar 8, 2020 •

edited

urandom commented Mar 8, 2020

urandom commented Mar 8, 2020

leaxoy commented Mar 9, 2020

leaxoy commented Mar 9, 2020

leaxoy commented Mar 9, 2020

ianlancetaylor commented Mar 10, 2020

maj-o commented Mar 14, 2020

urandom commented Mar 14, 2020

ianlancetaylor commented Mar 17, 2020

neakor commented Apr 7, 2020

ianlancetaylor commented Apr 7, 2020

proposal: Go 2: extend types out of package where it is defined. #37742

proposal: Go 2: extend types out of package where it is defined. #37742

Comments

leaxoy commented Mar 8, 2020 • edited

Existing way.

1. Define new types. For example:

2. Another way is embed in another type

Proposal way

1. Normal syntax without any breaking syntax.

2. Add new keyword like extend or ext.

3. Like 2 add new keyword but place it before method name.

Usage

1. use old _ import syntax

ianlancetaylor commented Mar 8, 2020

beoran commented Mar 8, 2020 • edited

urandom commented Mar 8, 2020

urandom commented Mar 8, 2020

leaxoy commented Mar 9, 2020

leaxoy commented Mar 9, 2020

leaxoy commented Mar 9, 2020

ianlancetaylor commented Mar 10, 2020

maj-o commented Mar 14, 2020

urandom commented Mar 14, 2020

ianlancetaylor commented Mar 17, 2020

neakor commented Apr 7, 2020

ianlancetaylor commented Apr 7, 2020

leaxoy commented Mar 8, 2020 •

edited

2. Add new keyword like `extend` or `ext`.

1. use old `_` import syntax

beoran commented Mar 8, 2020 •

edited