VIP: abstract methods in vyper

[charles-cooper]

Simple Summary

add abstract methods to the vyper language. use a top-level resolution block as an explicit, in-text declaration of programmer intent.

the text below was co-created with claude code and is a starting point for the final specification.

Motivation

This document outlines the design for adding abstract methods to the Vyper programming language. The goal is to enable library authors to provide reusable contract patterns while maintaining Vyper's core principles of readability, explicitness, and security.

Library authors currently face limitations when trying to provide reusable contract implementations. They often need to implement 95% of a pattern's functionality while leaving specific customization points for users. Without abstract methods, this requires either:

• Copy-pasting entire implementations
• Complex delegation patterns
• Sacrificing type safety

Abstract methods allow library authors to define contracts with "holes" that users fill in, similar to the template method pattern in object-oriented programming.

Design Goals

1. No spooky action at a distance - Module behavior must be understandable by reading the module itself
2. Explicit over implicit - All abstract method resolutions must be explicit
3. Compile-time resolution - No runtime dispatch or polymorphism
4. Prevent ambiguity - The diamond problem must be impossible
5. Maintain simplicity - The mental model must remain simple

Specification

Core Concepts

1. Libraries can define abstract methods that must be implemented by users
2. Libraries can provide implementations for other libraries' abstract methods
3. Compilation targets must explicitly resolve all abstract methods using a resolutions block
4. All resolution happens at compile time through code inlining

Syntax

Defining Abstract Methods in Libraries

# base_token.vy
@library

@abstract
def before_transfer(sender: address, recipient: address, amount: uint256): ...

@abstract
def after_transfer(sender: address, recipient: address, amount: uint256): ...

@external
def transfer(recipient: address, amount: uint256) -> bool:
    self.before_transfer(msg.sender, recipient, amount)
    # ... transfer logic ...
    return True

Providing Implementations in Libraries

# pausable_token.vy
import base_token

@library
uses: base_token

provides:
    base_token.before_transfer -> self._check_pause
    base_token.after_transfer -> self._after_transfer

@internal
def _check_pause(sender: address, recipient: address, amount: uint256):
    assert not self.paused, "Token is paused"

@internal
def _after_transfer(sender: address, recipient: address, amount: uint256):
    pass  # no-op

Resolution in Compilation Targets

# my_token.vy

import base_token
import pausable_token

resolutions:
    base_token.before_transfer: accept pausable_token._check_pause
    base_token.after_transfer: override pausable_token._log -> self._my_log
    base_token.on_mint -> self._mint_checks

uses: pausable_token

@internal
def _my_log(sender: address, recipient: address, amount: uint256):
    # Custom implementation
    pass

@internal
def _mint_checks(recipient: address, amount: uint256):
    # Implementation for abstract method
    pass

Resolution Syntax

• accept <provider>.<method> - Use the provided implementation
• override <provider>.<method> -> <implementation> - Replace provided implementation
• -> <implementation> - Provide fresh implementation (when no provider exists)

Key Rules

1. Libraries cannot override - Only provide or pass through
2. Explicit conflict resolution - Multiple providers require explicit choice
3. Complete resolution required - All reachable abstract methods must be in resolutions
4. Single library rule - A module can only use one library with abstract methods (prevents complexity)

Design Process and Rejected Alternatives

1. Inheritance-Based Approaches (Rejected)

Considered: Traditional OOP-style inheritance with method overriding

Rejected because:

• Violates "no spooky action at a distance" principle
• Inheritance chains make reasoning about behavior difficult
• Vyper explicitly avoids inheritance

2. Implicit Resolution (Rejected)

Considered: Automatically using the "most recent" or "most specific" implementation

Rejected because:

• Too implicit for Vyper's philosophy
• Can lead to surprising behavior
• Makes code review and auditing harder

3. Runtime Dispatch (Rejected)

Considered: Virtual method tables or dynamic dispatch

Rejected because:

• Performance overhead
• Complexity in understanding execution flow
• Against Vyper's principle of static verification

4. Multiple Template Instantiation (Rejected)

Considered: Allowing multiple templates/libraries with abstract methods per contract

Rejected because:

• Creates complex diamond problems
• Difficult to reason about method resolution order
• Significantly increases complexity

5. Cross-Module Abstract Methods Only (Rejected)

Considered: Abstract methods that can only be implemented across module boundaries

Rejected because:

• The diamond problem becomes unavoidable
• Complex resolution rules needed
• Libraries couldn't compose easily

6. Single-File Abstract Methods Only (Rejected)

Considered: Abstract methods only for forward declarations within one file

Rejected because:

• Doesn't solve the library author use case
• Too limited in functionality
• Doesn't enable code reuse

7. Strategy Pattern / Explicit Delegation (Rejected)

Considered: Using interfaces and explicit delegation instead of abstract methods

# Example of rejected pattern
@external
def transfer(recipient: address, amount: uint256, validator: IValidator) -> bool:
    validator.validate_transfer(msg.sender, recipient, amount)
    # ...

Rejected because:

• Changes contract APIs
• Less elegant than abstract methods
• Requires deploying separate contracts

8. Event-like Hook System (Rejected)

Considered: Multiple implementations that all get called

Rejected because:

• Ordering problems
• Performance overhead
• Too different from traditional abstract methods

9. Implicit accept (Considered, then Rejected)

Considered: Making accept the default, not requiring explicit keyword

Rejected because:

• Explicit is better than implicit
• accept makes intent clearer
• Helps with code review and auditing

Diamond Problem Resolution

The diamond problem is completely prevented through:

1. Explicit resolution requirement - When multiple libraries provide the same abstract method, compilation fails unless explicitly resolved
2. Single source of truth - Only the compilation target's resolutions block determines final bindings
3. No library override - Libraries cannot override other libraries' provisions

Example:

# If lib_a and lib_b both provide base.foo
resolutions:
    base.foo -> lib_a._foo  # Must explicitly choose
    # OR
    base.foo -> lib_b._foo
    # OR  
    base.foo -> self._my_foo

Benefits

1. Library reusability - Authors can provide mostly-complete implementations
2. Clear composition - All wiring visible at contract top
3. Type safety - Compile-time verification of all resolutions
4. No ambiguity - Diamond problem impossible
5. Performance - Zero runtime overhead
6. Auditability - Easy to understand what code does

Risks and Mitigations

1. Complexity - Mitigated by keeping rules simple and explicit
2. Learning curve - Mitigated by clear documentation and examples
3. Tooling updates - Mitigated by phased rollout

Conclusion

This design provides abstraction capabilities for library authors while maintaining Vyper's core philosophy. By requiring explicit resolution and preventing library overrides, we avoid the drawbacks of inheritance while enabling useful code reuse patterns.

The resolutions block serves as a single source of truth at the top-level compilation target, making contracts simpler to audit. All method dispatch is resolved at compile time, maintaining Vyper's performance characteristics and security properties.

Backwards Compatibility

No known backwards compatibility issues

Dependencies

#3722
#2431

References

Add any references that this VIP might reference (other VIPs/issues, links to blog posts, etc.)

Copyright

Copyright and related rights waived via CC0

[romanagureev]

What scares me in current solution is absence of any structure between abstract and redefined methods.

Critics

accept keyword

Basically means inheritance, moreover limited to chain and no diamond shape allowed. For example one module implementing _before_transfer and the other _after_transfer.

override keyword

Overrides are too complicated base_token.after_transfer: override pausable_token._log -> self._my_log. Overriding specific method call doesn't look right by design!

Single library rule

Too harsh limit. Most of libraries would need abstract methods as they are kind of events between libraries.

Proposal

In line with composition, abstract methods should be tiny modules. May be a proper analogue in python would be object of function/lambda function inserted in the class. So I propose to inline these functions directly and explicitly:

# Class-like
mod ERC20(erc20):
	exports: (
		# erc20._log,  # Can explicitly show no override
		pausable_token._before_transfer,
	)
	def _after_transfer():
		self._update_user()

and corresponding

@modifiable
def _before_transfer():
	...

pros:

• Explicitly show resolutions by either definition or provision from other modules.
• No tangled naming changes (like _before_transfer -> _check_pause).
• Less ambiguity for methods(whether they are implementation of abstract, target module functionality, or both).
• Possible to reuse methods explicitly via ERC20._before_transfer().
• Possible to add @modifiable decorator even to non-abstract methods.

cons:

• Impossible to reuse existing function. Though, exactly same abi or even input is rare, so some kind of wrapper would be always needed.
• How to properly treat importing module with modifications?
• If pausable_token has @modifiable methods, there is ambiguity to which version we would apply changes, especially if there are several needed. Here it makes sense to harsh limit to one, because using one library in several different ways for one target contract is bad architecture, better use external contracts then.

Rekt ideas

1. modifications keyword (erc20: and code under modifications: doesn't look pythonic)

# Keyword
modifications:
	erc20:
		exports: (
			pausable_token._before_transfer,
		)
		def _after_transfer():
			self._update_user()

2. Implement inheritance alongside the composability. When we reimplement or implement fully it means inheritance. For example, pausable_token.vy is token.vy, so it is inherited. But this breaks explicitness for used functions.

[Sporarum]

Hello,
This is a type of issue I've been thinking about a lot since discovering the many problems with java-style inheritance

I've come to view the following as my ideal solution:
(But I'm not sure vyper has all the building blocks, and please forgive my syntax mistakes)

1. Modules can be declared with parameters, that can be used on their inside
   • The type of parameter can be anything, including functions/lambdas
   • It is therefore possible to change the behaviour by passing different functions as input
2. Modules, once instantiated, can be named, to allow multiple to coexist

It then looks something like:

module counter(max: int, reset_on_max: bool, on_max: Callable[[], void]):
  count: int = 0

  def increment():
    count +=1
    if count == max:
      on_max()
      if reset_on_max:
         count = 0
    else if count > max:
      halt_and_catch_fire()

# In the same file or a different one:

@internal
def stop_pestering_us():
    send("Please leave us alone")

spam_counter = counter(max=10, reset_on_max=true, on_max=stop_pestering_us)

@external
def spam():
   spam_counter.increment()

We can also have a import keyword, which makes all external methods of the library external here as well

module MyModule():
  @external
  def foo(): ...

  @external
  def bar(): ...

import MyModule()
# Equivalent to
my_mod = MyModule()
@external
my_mod.foo
@external
my_mod.bar

(Personally I think it makes sense to make it a bit more verbose to declare external methods, as they are so important for security)

If there are some behavior we want to make customizable, but also provide a default implementation, we can use default arguments:

module foo(bar: Callable[[A, B], C] = lambda a, b: <implementation>):
# Or
def default_bar(a: A, b:B) -> C:
  <implementation>
module foo(bar: Callable[[A, B], C] = default_bar):

Adherence to design goals

1. No spooky action at a distance - Module behavior must be understandable by reading the module itself
   • Module behavior is only determined by its implementation and its inputs
2. Explicit over implicit - All abstract method resolutions must be explicit
   • The only resolution mechanism is passing values, which is explicit
3. Compile-time resolution - No runtime dispatch or polymorphism
   • We can only allow module arguments which are fully known at compile-time, which enables inlining
4. Prevent ambiguity - The diamond problem must be impossible
   • No diamond problem, if we have two instances, we can name them and use the one we want where we want it
5. Maintain simplicity - The mental model must remain simple
   • The mental model is passing values, in the same way we pass values to functions

Syntax comparison

Original Example

Defining Abstract Methods in Libraries

# base_token.vy
@library

@abstract
def before_transfer(sender: address, recipient: address, amount: uint256): ...

@external
def transfer(recipient: address, amount: uint256) -> bool:
    self.before_transfer(msg.sender, recipient, amount)
    # ... transfer logic ...
    return True

Becomes

# base_token.vy
module base_token(before_transfer: Callable[[address, address, uint256], ...]):

  @external
  def transfer(recipient: address, amount: uint256) -> bool:
    self.before_transfer(msg.sender, recipient, amount)
    # ... transfer logic ...
    return True

Providing Implementations in Libraries

# pausable_token.vy
@library
uses: base_token

provides:
    base_token.before_transfer -> self._check_pause

@internal
def _check_pause(sender: address, recipient: address, amount: uint256):
    assert not self.paused, "Token is paused"

Becomes

# pausable_token.vy


@internal
def default_check_pause(sender: address, recipient: address, amount: uint256):
    assert not self.paused, "Token is paused"

module pausable_token(
  check_paused: Callable[[address, address, uint256], None] = default_check_pause
  on_mint: Callable[[address, uint256], None]
): # Added parameters used below
  
    import base_token(before_transfer = self._check_pause)
    # or
    base_token = base_token(before_transfer = self._check_pause)
    @external base_token.transfer

Resolution in Compilation Targets

# my_token.vy
resolutions:
    base_token.before_transfer: accept pausable_token._check_pause
    base_token.after_transfer: override pausable_token._log -> self._my_log
    base_token.on_mint -> self._mint_checks

uses: pausable_token

@internal
def _my_log(sender: address, recipient: address, amount: uint256):
    # Custom implementation
    pass

@internal
def _mint_checks(recipient: address, amount: uint256):
    # Implementation for abstract method
    pass

Becomes

# my_token.vy

import pausable_token(
 _log = self._my_log
  on_mint = self._mint_checks
  # pausable_token._check_pause uses default implementation because nothing is passed
)

@internal
def _my_log(sender: address, recipient: address, amount: uint256):
    # Custom implementation
    pass

@internal
def _mint_checks(recipient: address, amount: uint256):
    # Implementation for abstract method
    pass

[Sporarum]

explicit @override proposal

Instead of having an isolated provides/resolutions block at the top, overriding methods are declared with an @override annotation which contains the identifier of the overridden method.
This helps cut on the repetition while keeping everything explicit.

For the purposes of this proposal, only internal methods can be abstract or override, external methods already have interface and export which serve similar purposes, unifying these two systems should be discussed at a later time.

• A contract/module overrides an abstract method by declaring a method with an @override annotation containing a reference to the abstract method
  • Example: @override(foo.bar)\n def qux(<parameters of foo.bar>): ...
• A contract must override all abstract methods of the modules it implements (and cannot declare any)
• A module must override all abstract methods of the module it implements/uses, and can declare new ones
• A module can delegate an abstract method to its children by adding it to a no_override block
  • This counts as both overriding the original, and declaring a new abstract method
• A contract/module can use the default implementation of an abstract method by adding it to an accept block
  • This counts as overriding the original, which must have a body

This combination of override/abstact annotations and accept/no_override blocks means by just looking at a single module it is possible to know which methods a child module needs to override (abstact and no_override), and which methods of its parent it overrides (override and accept).

The no_override block is not strictly necessary, since it can be emulated by creating an abstract method which overrides the parent method:

no_override: (
   foo.bar
)
# Equivalent to
@abstract
@override(foo.bar)
def bar(<params of foo.bar>): ...

It is however very verbose for something that might happen quite often, and as such the no_override block is included in this proposal.

Unlike the initial proposal, it is not possible to use one module's methods to override another's, instead the user has to write a forwarder method (which could be inlined by the compiler):

@override(lib1.foo)
def my_override(...):
    return lib2.bar(...)

Full example:

# base_token.vy
@library

@abstract
def before_transfer(sender: address, recipient: address, amount: uint256): ...

@abstract
def after_transfer(sender: address, recipient: address, amount: uint256): ...

@abstract
def on_mint(recipient: address, amount: uint256): ...

@external
def transfer(recipient: address, amount: uint256) -> bool:
    self.before_transfer(msg.sender, recipient, amount)
    # ... transfer logic ...
    return True

# pausable_token.vy
import base_token

@library
uses: base_token

exports: (
    base_token.transfer,
)

no_override: (
    base_token.on_mint,
)

@override(base_token.before_transfer)
def _check_pause(sender: address, recipient: address, amount: uint256):
    assert not self.paused, "Token is paused"

# Changes the name, but still makes it abstract
@abstract
@override(base_token.after_transfer)
def _log(sender: address, recipient: address, amount: uint256): ...

# my_token.vy

import pausable_token

accept: (
    pausable_token._check_pause
)

uses: pausable_token

exports: (
    pausable_token.transfer,
)

@override(pausable_token._log)
def _my_log(sender: address, recipient: address, amount: uint256):
    # Custom implementation
    pass

@override(base_token.on_mint)
def _mint_checks(recipient: address, amount: uint256):
    # Implementation for abstract method
    pass

The name of the annotations/blocks is not final, I just needed something to be able to talk about it
In particular, maybe delegate_override is better than no_override

[Sporarum]

@charles-cooper proposes reabstract instead of no_override

[charles-cooper]

A contract must override all abstract methods of the modules it implements (and cannot declare any)
A module must override all abstract methods of the module it implements/uses, and can declare new ones

i think we can relax this restriction as well. so providing implementations for all the abstract methods is not necessary

[cyberthirst]

i probably like the @override proposal the best, but have a few questions/remarks

how are collisions handled? assume A and B both uses: C and both override C.foo. A top-level D composes A and B - do we forceaccept on some of the variants or compilation failure? or maybe we can even accept both in some cases, e.g.

resolves: (
    C.before_transfer := (Pausable._check_pause, Blacklist._check_allowed),
)

assume we use import aliases, e.g. import foo as f and import foobar as f, then the path for the method could collide which could make the user think the same method is being overriden. should we use "desugared" qualified paths?

if we override a method, how do we treat it's decorators? mutability, reentrancy, payability etc. Can those be overriden too, or do we have to maintain? say with mutability we might want to override only with the same level or lower - e.g. we can't override pure with view, but the opposite works

can an overriden method be further overriden? or do we seal. in case we allow further overriding, i propose @final keyword which would forbid it in case the library writer required his code gets called as is

charles wrote

i think we can relax this restriction as well. so providing implementations for all the abstract methods is not necessary

this is the fine line between verbosity and explicitness, i think dropping this requirement will increase ambiguity. i'm leaning towards the original requirement

@charles-cooper proposes reabstract instead of no_override

but the method still hasn't been overriden, so it's already abstract no? i prefer defer, it plays nicely with accept

[Sporarum]

how are collisions handled? assume A and B both uses: C and both override C.foo. A top-level D composes A and B - do we forceaccept on some of the variants or compilation failure?

My idea was that both A and B have their own separate state, so there is no issue: A.foo is distinct from B.foo, and their side-effects don't interact
However @charles-cooper told me we should use a singular state for abstract modules, to be in line with what we do for uses/initializes

assume we use import aliases, e.g. import foo as f and import foobar as f, then the path for the method could collide which could make the user think the same method is being overriden. should we use "desugared" qualified paths?

This is a name clash and should fail earlier in the compiler (and it probably already does)

if we override a method, how do we treat it's decorators? mutability, reentrancy, payability etc. Can those be overriden too, or do we have to maintain? say with mutability we might want to override only with the same level or lower - e.g. we can't override pure with view, but the opposite works

I hadn't thought of it yet, but it seems fine to override with any function that is a subtype of the original (including mutability)

can an overriden method be further overriden? or do we seal. in case we allow further overriding, i propose @final keyword which would forbid it in case the library writer required his code gets called as is

No, it has to explicitly be marked @abstract to allow downstream override (and it's probably a code smell ?)

charles wrote

i think we can relax this restriction as well. so providing implementations for all the abstract methods is not necessary

this is the fine line between verbosity and explicitness, i think dropping this requirement will increase ambiguity. i'm leaning towards the original requirement

I agree

@charles-cooper proposes reabstract instead of no_override

but the method still hasn't been overriden, so it's already abstract no? i prefer defer, it plays nicely with accept

reabstract makes explicit the mechanism; we both override and abstract the method to pass it down:

no_override: (
   foo.bar
)
# Equivalent to
@abstract
@override(foo.bar)
def bar(<params of foo.bar>):
    return foo.bar(<params of foo.bar>)

However I think we should always try to make the intent clear instead of the mechanism, so maybe defer is better

Overall this proposal is very centered around the idea of each abstract module having its own state, and doesn't work at all with a single shared state

[Sporarum]

Mechanism PoC

The goal of this proposal is to give a strict spec for the smallest abstract/override system possible.
This will allow us to see what is and isn't possible, as well as to develop a mental model of what is going on.
The focus is not at all on the syntax, which aims to be as explicit as possible to make the system easier, do not expect QoL.

Even if implemented perfectly, this would therefore not be suitable for release !

Syntax/Well-formedness

An abstract module is one starting with @abstract (which must not be decorating a method).
An abstract method is one decorated with @abstract.
Only abstract modules can contain abstract methods.
Abstract methods must have ... as their body.
A concrete method is one which is not an abstract method.

A contract can contain at most one override: statement, which if present must be followed by the identifier of an abstract module.
An override method is one decorated with @abstract(id).

A contract with an override statement must decorate methods with @override(id) such that:

• For every abstract method id, exactly one method is decorated with @override(id)
  • Both methods must have the same name, decorators¹ and type (same signature, return type and mutability)
  • The overriding method must not be decorated with another @override
• Any method decorated with @override that is not covered by the above is invalid and causes an error
  If the abstract module has a constructor, the contract must call it exactly once within its own (and nowhere else).

Both abstract and concrete methods can be called from inside the abstract module.
Only concrete methods of the abstract module can be called from the contract.

Example:

library.vy

@abstract

offset: int256

@deploy
def __init__():
	offset = 4

@abstract
def foo() -> int256: ...

def bar():
  return this.foo() + this.offset

contract.vy

import library

override: library

base: int256

@deploy
def __init__():
	library.__init__()
	base = 2

@override(library.foo)
def foo() -> int256:
  return base
  
@external
def query() -> int256:
  # library.foo() # error: `library.foo` is abstract, do you mean `this.foo` ?
  return library.bar()

Semantics

The contract and abstract module behave as usual, except for the following case:

• When the abstract module calls one of its abstract methods, this call is instead replaced by a call to the corresponding override method.

Footnotes

1. Except @abstract and @override. ↩

[Sporarum]

initializes-based proposal

Design constraints

1. Each module should only have a single state per contract, even if it is abstract
   1. This also includes modules that are not exposed to the contract (if they are confined to libraries)
2. A module which overrides another should have its overrides actually affect the overridden module
   1. In other words, it is not possible to re-override an abstract method
3. Intent should be as clear as possible

Example

generic.vy

_counter: uint256

@deploy
def __init__():
	self._counter = 0

def increment():
  self._counter += 1

def counter_state() -> uint256:
	return _counter

@abstract
def foo(x: uint256) -> uint256: ...

@abstract
def bar() -> uint256: ...

specialized.vy

import generic

initializes: generic

@deploy
def __init__():
	generic.__init__()

@override(generic) # points to module: same method name
def foo(x: uint256, y: uint256 = 0) -> uint256: # adds a parameter
	return x + y

@override(generic.bar) # points to method: can rename method
def not_bar() -> uint256:
	return this.default() + generic.counter()

@abstract
def default() -> uint256: ...

contract.vy

import specialized

initializes: specialized

@deploy
def __init__():
	specialized.__init__()

@override
def default() -> uint256:
	return 0

def compute():
	specialized.foo(specialized.not_bar(), 54)

Spec

Definitions

An abstract method is an internal method annotated with @abstract.
An abstract module is a module containing at least one abstract method.
A method c overrides an abstract method a if and only if:

1. c is decorated with @override(id) and
   1. id points to a, or
   2. id points to a's parent module and c has the same name as a
2. c's type is a subtype of a's:
   1. Each parameter of a has a parameter in c with the same name, position and default value
   2. Every parameter of c which is not in a must have a default value
   3. Each parameter of c is a supertype of the corresponding parameter of a
   4. The return type of c is a subtype of the return type of a
   5. The mutability of c is at least as strict as that of a
   6. Each other decorator is identical
      1. I.e. all decorators except @abstract, @overrides, and mutability decorators
3. Consequences of the above:
   1. A single method can override multiple other methods
   2. Method names can be different if @overrides points to the abstract method
   3. The name of the abstract method can be implied if it has the same name as the overriding one
   4. The overriding method can have more parameters than the abstract one, provided they are the rightmost ones and have default values
   5. An overriding method can itself be @abstract

A module/contract overrides an abstract method if it contains exactly one method which overrides it.
A module/contract overrides an abstract module if it overrides every one of its methods.

Well-Formedness Rules

A method must override as many methods as it has @override decorators (i.e. all decorators must be valid).
The constructor of a module cannot be abstract.
An abstract method's body must be ... (no default implementation).
If a module or contract initializes an abstract module, then it must override it.
If a module or contract doesn't initializes an abstract module, then the former cannot override any of the latter's methods.
A contract cannot posses abstract methods.
An abstract module can call all its methods (abstract or not).
A module or contract cannot call a method a it overrides, instead it can call the method which overrides a.
A method c overriding a method a counts as a call from a to c for the purposes of mutual recursion detection, see [[#Appendix]] for an example of the problems this fixes.

On top of the above, the delegate statement can be used to reduce boilerplate:
On the lhs of delegate is a sequence of abstract method identifiers.
For each of them (called a), a forwarder f is created:

1. f has the same name as a
2. f has the same type as a
3. f overrides a
4. f is abstract
5. There must not be a member in scope which would clash with f
6. f acts as a regular abstract method, and can be referred to as this.<name of a>

Execution Rules

All calls to an abstract method are replaced by calls to the method which overrides it.

Discussion

1. Should we add a specific marker to abstract modules ?
2. Can abstract modules be uses-ed ?
3. Given this is starting to look a lot less like inheritance, should we change the terminology away from @abstract/@override ?
   1. Perhaps as proposed by Roman Agureev to hookpoint/something
4. Overriding default parameters is not allowed by the above, should we allow it ?
   1. One option would be that ... when used as default value, must be replaced by a concrete value in the (non-abstract) overriding method
5. This proposal aims to be as permissive as possible on the overriding methods, should anything be tightened ?
6. Perhaps the definition of method subtyping as described in the definition of "overrides" is not suitable for other purposes and should not be used outside of this feature
7. delegate could be replaced by @abstract \n exports since exports already has this notion of forwarding something
   1. External methods would not be allowed in this annotated form, as it could lead to confusion and/or deception
   2. We could eventually replace the bare exports by @external \n exports to reinforce the symmetry
8. Abstract methods cannot have a default implementation, I'm still looking for a way to cleanly integrate it in the current system.
9. As-is, if a module delegates method m from module p, it cannot call it as p.m, and must instead call it as self.m. This makes sure there is only ever one way to refer to a method, but might create some confusion.

Appendix

# file1

def a():
	return self.b() # a calls b

@abstract
def b(): ...

#file2

import file1

initializes: file1

@override
def b():
	return file1.a() # b calls a: infinite loop !

[Sporarum]

Addendum 1

We should forbid renaming the override to make it harder to write confusing code.
(The behaviour is still possible by writing a forwarder manually.)

Therefore point 1. of definitions should read instead:
c is decorated with @override(id), id is a's parent module, and c has the same name as a

Example:

@override(Foo)
def bar(x: uint256) : # overrides Foo.bar
    return x

@override(Foo.bar) # Error: Foo.bar is not a module
def baz(x: uint256) :
    return x

[Sporarum]

Addendum 2

In well-formedness rules:
Update

A method must override as many methods as it has @OverRide decorators (i.e. all decorators must be valid).
to
All override decorators on a method must be valid (lead to an override)

Change semantic rules to:

As soon as abstract methods have been resolved, calls to an abstract method are treated as calls to the method which overrides it.

Remove:

A method c overriding a method a counts as a call from a to c for the purposes of mutual recursion detection, see [[#Appendix]] for an example of the problems this fixes.

New discussion points:

1. Module without state do not get initialized, but we still need to be able to override them
2. We should add a system for default implementation
3. delegate should be changed to a different keyword to avoid confusion with the ethereum concept of delegating calls
   1. Should we use the proposed @abstract exports