Thank you for your proposal.

Can you please explain why you need to change the language to achieve this. Is there no other way to do this without changing the language? You mention that you have already forked the google/martian repository. Why is this not sufficient? For example, have you considered contributing your improvement upstream?

This just looks like dependency hell to me. If you override a function from package foo, every package that depends on foo (including foo itself) also depends on you now. Instant cyclic dependency. I just don't see how this is practical from either a compiler standpoint or an organizational standpoint.

@ccbrown As a app, we can safe override upstream package function. It will benefit not to fork upstream and maintain the huge repository.

@davecheney I have no idea how to deal this with golang, in other Programming languge, like java, php, or python. CSharp
We can easy extends class. and override one function of origin class.

See csharp polymorphism
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/polymorphism

public class Shape
{
    // A few example members
    public int X { get; private set; }
    public int Y { get; private set; }
    public int Height { get; set; }
    public int Width { get; set; }
   
    // Virtual method
    public virtual void Draw()
    {
        Console.WriteLine("Performing base class drawing tasks");
    }
}

class Circle : Shape
{
    public override void Draw()
    {
        // Code to draw a circle...
        Console.WriteLine("Drawing a circle");
        base.Draw();
    }
}
class Rectangle : Shape
{
    public override void Draw()
    {
        // Code to draw a rectangle...
        Console.WriteLine("Drawing a rectangle");
        base.Draw();
    }
}
class Triangle : Shape
{
    public override void Draw()
    {
        // Code to draw a triangle...
        Console.WriteLine("Drawing a triangle");
        base.Draw();
    }
}

class Program
{
    static void Main(string[] args)
    {
        // Polymorphism at work #1: a Rectangle, Triangle and Circle
        // can all be used whereever a Shape is expected. No cast is
        // required because an implicit conversion exists from a derived 
        // class to its base class.
        System.Collections.Generic.List<Shape> shapes = new System.Collections.Generic.List<Shape>();
        shapes.Add(new Rectangle());
        shapes.Add(new Triangle());
        shapes.Add(new Circle());

        // Polymorphism at work #2: the virtual method Draw is
        // invoked on each of the derived classes, not the base class.
        foreach (Shape s in shapes)
        {
            s.Draw();
        }

        // Keep the console open in debug mode.
        Console.WriteLine("Press any key to exit.");
        Console.ReadKey();
    }

}

We can easy extends class. and override one function of origin class.

Go has no classes and non-interface types have no inheritance concept.

@cznic, as the example. package github.com/google/martian has

func (p *Proxy) connect(req *http.Request) (*http.Response, net.Conn, error)  

function connect belong to struct Proxy

I need to replace this function to support socks5 proxy dialer

https://github.com/google/martian/pull/214/files
The PR i submit to google/martian. not yet processed. seems they will not accept .
So i have to fork the repository (It should not do like this kind hard work)

@netroby: If they do not accept your submit, maybe they do accept this: If I know that there may be a different implementation of something I declare a function type. And any instance
of a class has a property of this type (usualy nil). But if this property is set, this function will be called not the default function. This is accepable. I think (hope).

In general, part of authoring a package means you have control over what you allow clients to override and what you do not. If you haven't designed your package to allow an override, clients should not be able to override it. Otherwise you end up with clients that depend on internal details and then you can't ever change those internal details, even though you tried to keep them internal. We understand that this is different from languages like Python where monkey-patching is common, but it's a key part of scalable software development to have hard boundaries like this.

If a package you want to use doesn't enable the overrides you need, the only two options are either fork that package or ask the upstream maintainers to add the kind of override you want. But we aren't going to add support in the language or toolchain for arbitrary overrides, because it makes it too difficult to scale to large software projects.